From brad.beveridge at gmail.com  Sun Oct 22 00:52:54 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Sat, 21 Oct 2006 17:52:54 -0700
Subject: [vial-devel] test
Message-ID: <de95dc6f0610211752k5091b32an33a2e06842800ce8@mail.gmail.com>

Just a test


From laynor at gmail.com  Sun Oct 22 15:58:28 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Sun, 22 Oct 2006 17:58:28 +0200
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
Message-ID: <d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>

I already ran make in the ncurses-cffi
directory, but it seems that it's not the point...
running make i get the ncurses.lisp and ncurses-cffi.lisp files, but loading
with asdf
says that thing anyway... I also tried to compile the lisp files manually,
and reload
with asdf but I just get the same error. Is it possible that it's a problem
with
common lisp controller?

On 10/22/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
>
> On 22/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > Hi, i was trying to have a test run of vial, but when i load it with
> >
> > (asdf:operate 'asdf:load-op 'vial)
> >
> > it says
> >
> > debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD
> "initial
> > thread" {A820561}>: The path
> >
> #P"/var/cache/common-lisp-controller/1000/sbcl/local/home/ale/src/vial/ncurses-cffi/ncurses.fasl"
> > does not exist.
> >
> > I actually don't know what to do, should i manually compile
> > ncurses.lisp
> > file (the output of swig) and copy it to the that path?
> > I guess there's a
> > better way to do it, but don't know how :)
> >
> >
> >
> Hi Alessandro, please feel free to mail to the vial mailing list.  If
> you have SWIG you can just run 'make' from the cffi directory.
> Or you can do another "darcs get", I've checked that file in - it
> should have been there from the start.
>
> Cheers
> Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061022/71512732/attachment.html>

From brad.beveridge at gmail.com  Sun Oct 22 16:13:13 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Sun, 22 Oct 2006 09:13:13 -0700
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
	<d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
Message-ID: <de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>

On 22/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> I already ran make in the ncurses-cffi directory, but it seems
> that it's not the point...
> running make i get the ncurses.lisp and ncurses-cffi.lisp files, but loading
> with asdf
> says that thing anyway... I also tried to compile the lisp files manually,
> and reload
> with asdf but I just get the same error. Is it possible that it's a problem
> with
> common lisp controller?
>
Hmm, I don't use common lisp controller - that could be the issue.
The path looks a little strange, as if you have installed Vial under
the common lisp controller directory?
I also just use (require 'vial) on SBCL to load the asdf file.

I just looked at CL controller, I am pretty sure that is the issue.
I'm afraid that you'll have to figure that one out without me - I
manually install the packages that I need and then symlink the ASDF
file to ~/.sbcl/systems/

Let me know how you get on, sorry I couldn't help more.

Cheers
Brad


From brad.beveridge at gmail.com  Sun Oct 22 16:55:55 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Sun, 22 Oct 2006 09:55:55 -0700
Subject: [vial-devel] Re: [slim-vim] Vial has a home on common-lisp.net
In-Reply-To: <20061022094406.GB7350@linux>
References: <de95dc6f0610211748n1e479ca9je1348168d32808b7@mail.gmail.com>
	<20061022094406.GB7350@linux>
Message-ID: <de95dc6f0610220955g3945545epacd89195b0f91747@mail.gmail.com>

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.


From laynor at gmail.com  Sun Oct 22 22:35:17 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Mon, 23 Oct 2006 00:35:17 +0200
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
	<d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
	<de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>
Message-ID: <d0e2f05e0610221535u2cf3e277l79129a0daf057b4f@mail.gmail.com>

I managed to make it compile, and it seems it was a system definition
problem.
I attach here the fixed file, the fixes are documented through comments,
just search for FIX and MOVED :)

Now I have another problem. when i run vial
(with *(v**ial:vial)*),
the editor opens, but when i try
to write something it prints out (lots of) garbage, that seems something
like the interpreter's output. Example garbage is shown in the other
attached file, garbage.txt
Let me know if it's somewhat "forbidden" to send attachments here, and how
to send (supposed to be) fixes and patches :)
__
Alessandro
__
Alessandro

On 10/22/06, Brad Beveridge < brad.beveridge at gmail.com> wrote:
>
> On 22/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > I already ran make in the ncurses-cffi directory, but it seems
> > that it's not the point...
> > running make i get the ncurses.lisp and ncurses-cffi.lisp files, but
> loading
> > with asdf
> > says that thing anyway... I also tried to compile the lisp files
> manually,
> > and reload
> > with asdf but I just get the same error. Is it possible that it's a
> problem
> > with
> > common lisp controller?
> >
> Hmm, I don't use common lisp controller - that could be the issue.
> The path looks a little strange, as if you have installed Vial under
> the common lisp controller directory?
> I also just use (require 'vial) on SBCL to load the asdf file.
>
> I just looked at CL controller, I am pretty sure that is the issue.
> I'm afraid that you'll have to figure that one out without me - I
> manually install the packages that I need and then symlink the ASDF
> file to ~/.sbcl/systems/
>
> Let me know how you get on, sorry I couldn't help more.
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061023/4f1a2c89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vial.asd
Type: application/octet-stream
Size: 1705 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061023/4f1a2c89/attachment.obj>
-------------- next part --------------
*RRRRRRRRRRRdo-insert-key-special |<CR>|20 0 #<CURSOR {B944F61}>fnmgbgvnm,bnvcb<CR>gkdsjflgkjsdflgsdf<CR>gsd<CR>fgs<CR>dRRRRdo-insert-key-special |<CR>|20 0 #<CURSOR {B944F61}>fasdfasdf                                                       
                                getkey    <CR>       asdf Rendering window Window: 55 120 0 #<CURSOR {B944F61}>                                                       3        Rendering window Window: 55 120 0 #<CURSOR {B944F61}>   Action OP End 1                                         Rendering window Window: 55 120 0 #<CURSOR {B944F61}>                          enter-insert-mode                                                                                                 
                       Rendering window Window: 55 120 0 #<CURSOR {B944F61}>                                            
                                                                            Processing insert i                         
                                                                                               Rendering window Window: 55 120 0 #<CURSOR {B944F61}>                                                                                                                        Rendering window Window: 55 120 0 #<CURSOR {B944F61}>                                       
                                                                                 a  

From brad.beveridge at gmail.com  Sun Oct 22 22:50:00 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Sun, 22 Oct 2006 15:50:00 -0700
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <d0e2f05e0610221535u2cf3e277l79129a0daf057b4f@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
	<d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
	<de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>
	<d0e2f05e0610221535u2cf3e277l79129a0daf057b4f@mail.gmail.com>
Message-ID: <de95dc6f0610221550k78ca9c66g70daeba6f6b6173b@mail.gmail.com>

On 22/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> I managed to make it compile, and it seems it was a system definition
> problem.
>  I attach here the fixed file, the fixes are documented through comments,
> just search for FIX and MOVED :)
>
> Now I have another problem. when i run vial
> (with (vial:vial)),
> the editor opens, but when i try to write something it
> prints out (lots of) garbage, that seems something like the
> interpreter's output. Example garbage is shown in the other attached file,
> garbage.txt
> Let me know if it's somewhat "forbidden" to send attachments here, and how
> to send (supposed to be) fixes and patches :)

Ah.  The output is debugging that goes to out *standard-output*.  I
have developed Vial using Slime and Emacs as a debugger.  Slime
rebinds the standard output and error streams, so for me that output
appears in Slime.  I would suggest that for right now developing by
using Slime as a REPL and debugger is probably a good idea.
Otherwise, you can rebind those streams (to NIL?) so that they don't
output to the screen.

Also, I appear to have a bug - the very first time that Vial runs the
screen doesn't refresh until a key is pressed.  I haven't figured out
why that is yet :)

Thanks for the updated vial.asd - I'm also a noob with ASDF, so for
right now I'm not worried about doing it "right", just that it works.

I don't mind patches and files being sent here as attachments, but I
would prefer that patches are created with darcs and are attached with
a commit comment.  I've not used darcs over email that much, but it
should work pretty well.

Also, if you wouldn't mind posting at the bottom when you reply I
would appreciate it :)

Cheers
Brad


From laynor at gmail.com  Sun Oct 22 23:11:40 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Mon, 23 Oct 2006 01:11:40 +0200
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <de95dc6f0610221550k78ca9c66g70daeba6f6b6173b@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
	<d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
	<de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>
	<d0e2f05e0610221535u2cf3e277l79129a0daf057b4f@mail.gmail.com>
	<de95dc6f0610221550k78ca9c66g70daeba6f6b6173b@mail.gmail.com>
Message-ID: <d0e2f05e0610221611r5629e1edhe08d5446584eaf1b@mail.gmail.com>

On 10/23/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
>
>
> Ah.  The output is debugging that goes to out *standard-output*.  I
> have developed Vial using Slime and Emacs as a debugger.  Slime
> rebinds the standard output and error streams, so for me that output
> appears in Slime.  I would suggest that for right now developing by
> using Slime as a REPL and debugger is probably a good idea.
> Otherwise, you can rebind those streams (to NIL?) so that they don't
> output to the screen.
>
> Also, I appear to have a bug - the very first time that Vial runs the
> screen doesn't refresh until a key is pressed.  I haven't figured out
> why that is yet :)
>
> Thanks for the updated vial.asd - I'm also a noob with ASDF, so for
> right now I'm not worried about doing it "right", just that it works.
>
> I don't mind patches and files being sent here as attachments, but I
> would prefer that patches are created with darcs and are attached with
> a commit comment.  I've not used darcs over email that much, but it
> should work pretty well.
>
> Also, if you wouldn't mind posting at the bottom when you reply I
> would appreciate it :)
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>
No problems about posting at the bottom, I didn't try it in emacs because i
was just doing a test run and the repl was fine enough for it :)
I'm an ASDF noob too, so we're in the same boat!
I'll have a look at darcs to see how it works, 'cause I'm a darcs noob too,
I just used it for my home directory and configuration files.
Anyway, i'm just pleased for how fast you answer.
__
Alessandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061023/7ddc3c8f/attachment.html>

From brad.beveridge at gmail.com  Sun Oct 22 23:16:33 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Sun, 22 Oct 2006 16:16:33 -0700
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <d0e2f05e0610221611r5629e1edhe08d5446584eaf1b@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
	<d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
	<de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>
	<d0e2f05e0610221535u2cf3e277l79129a0daf057b4f@mail.gmail.com>
	<de95dc6f0610221550k78ca9c66g70daeba6f6b6173b@mail.gmail.com>
	<d0e2f05e0610221611r5629e1edhe08d5446584eaf1b@mail.gmail.com>
Message-ID: <de95dc6f0610221616s2f3a5b84ud73f90868b5f9a21@mail.gmail.com>

On 22/10/06, Alessandro Piras <laynor at gmail.com> wrote:
>
>
> On 10/23/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> >
> > Ah.  The output is debugging that goes to out *standard-output*.  I
> > have developed Vial using Slime and Emacs as a debugger.  Slime
> > rebinds the standard output and error streams, so for me that output
> > appears in Slime.  I would suggest that for right now developing by
> > using Slime as a REPL and debugger is probably a good idea.
> > Otherwise, you can rebind those streams (to NIL?) so that they don't
> > output to the screen.
> >
> > Also, I appear to have a bug - the very first time that Vial runs the
> > screen doesn't refresh until a key is pressed.  I haven't figured out
> > why that is yet :)
> >
> > Thanks for the updated vial.asd - I'm also a noob with ASDF, so for
> > right now I'm not worried about doing it "right", just that it works.
> >
> > I don't mind patches and files being sent here as attachments, but I
> > would prefer that patches are created with darcs and are attached with
> > a commit comment.  I've not used darcs over email that much, but it
> > should work pretty well.
> >
> > Also, if you wouldn't mind posting at the bottom when you reply I
> > would appreciate it :)
> >
> > Cheers
> > Brad
> > _______________________________________________
> > vial-devel mailing list
> > vial-devel at common-lisp.net
> >
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> >
>  No problems about posting at the bottom, I didn't try it in emacs because i
> was just doing a test run and the repl was fine enough for it :)
> I'm an ASDF noob too, so we're in the same boat!
> I'll have a look at darcs to see how it works, 'cause I'm a darcs noob too,
> I just used it for my home directory and configuration files.
> Anyway, i'm just pleased for how fast you answer.

No problems, it's the weekend & I'm happy to have somebody else about.
I'm going to start an IRC channel, #vial.

Cheers
Brad


From laynor at gmail.com  Sun Oct 22 23:29:11 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Mon, 23 Oct 2006 01:29:11 +0200
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <de95dc6f0610221616s2f3a5b84ud73f90868b5f9a21@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
	<d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
	<de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>
	<d0e2f05e0610221535u2cf3e277l79129a0daf057b4f@mail.gmail.com>
	<de95dc6f0610221550k78ca9c66g70daeba6f6b6173b@mail.gmail.com>
	<d0e2f05e0610221611r5629e1edhe08d5446584eaf1b@mail.gmail.com>
	<de95dc6f0610221616s2f3a5b84ud73f90868b5f9a21@mail.gmail.com>
Message-ID: <d0e2f05e0610221629n54bedad1w1b37c5aaf7cd864d@mail.gmail.com>

On 10/23/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
>
>
> No problems, it's the weekend & I'm happy to have somebody else about.
> I'm going to start an IRC channel, #vial.
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>
In which server? freenode?
Anyway, i forgot to ask you how to start vial from emacs/slime.
Of course it doesn't open a terminal window automatically...
So how to start it and try it using emacs/slime?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061023/3ace0ce3/attachment.html>

From brad.beveridge at gmail.com  Sun Oct 22 23:31:45 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Sun, 22 Oct 2006 16:31:45 -0700
Subject: [vial-devel] Re: vial, ncurses-cffi
In-Reply-To: <d0e2f05e0610221629n54bedad1w1b37c5aaf7cd864d@mail.gmail.com>
References: <d0e2f05e0610220836u2302851naea59d59afaa3f64@mail.gmail.com>
	<de95dc6f0610220842m12c8a0ednc6bafe8eca9ed083@mail.gmail.com>
	<d0e2f05e0610220858q561a0c6bof5c2bb8a970b6a7e@mail.gmail.com>
	<de95dc6f0610220913n7b3003asbf47b2ad98a579e5@mail.gmail.com>
	<d0e2f05e0610221535u2cf3e277l79129a0daf057b4f@mail.gmail.com>
	<de95dc6f0610221550k78ca9c66g70daeba6f6b6173b@mail.gmail.com>
	<d0e2f05e0610221611r5629e1edhe08d5446584eaf1b@mail.gmail.com>
	<de95dc6f0610221616s2f3a5b84ud73f90868b5f9a21@mail.gmail.com>
	<d0e2f05e0610221629n54bedad1w1b37c5aaf7cd864d@mail.gmail.com>
Message-ID: <de95dc6f0610221631l2783d97uf5e3ea9d5dd03e57@mail.gmail.com>

On 22/10/06, Alessandro Piras <laynor at gmail.com> wrote:
>
>
> On 10/23/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> >
> > No problems, it's the weekend & I'm happy to have somebody else about.
> > I'm going to start an IRC channel, #vial.
> >
> > Cheers
> > Brad
> > _______________________________________________
> > vial-devel mailing list
> > vial-devel at common-lisp.net
> >
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> >
>  In which server? freenode?
> Anyway, i forgot to ask you how to start vial from emacs/slime.
> Of course it doesn't open a terminal window automatically...
>  So how to start it and try it using emacs/slime?

Yes, freenode.
My .sbclrc file has the lines
(require 'swank)
(swank:create-swank-server 4005)

I then start SBCL from the console as usual, and connect to it from
Slime with Meta-x slime-connect.

Cheers
Brad


From laynor at gmail.com  Mon Oct 23 03:25:46 2006
From: laynor at gmail.com (laynor at gmail.com)
Date: Sun, 22 Oct 2006 20:25:46 -0700 (PDT)
Subject: [vial-devel] darcs patch: clear-current-search, :noh ex command
Message-ID: <453c363a.2d0aeaae.66cf.704e@mx.google.com>

Mon Oct 23 04:33:39 CEST 2006  laynor at gmail.com
  * clear-current-search, :noh ex command
  Added ex command 
  :noh
  It clears the current search, and removes highlight.
  Got rid of some code duplication introduced defining remove-highlight, and
  using it in both search-forward-highlight-all and clear-current-search
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clear_current_search_-_noh-ex-command.dpatch
Type: text/x-darcs-patch
Size: 4560 bytes
Desc: A darcs patch for your repository!
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061022/c2d86320/attachment.bin>

From laynor at gmail.com  Mon Oct 23 16:22:13 2006
From: laynor at gmail.com (laynor at gmail.com)
Date: Mon, 23 Oct 2006 09:22:13 -0700 (PDT)
Subject: [vial-devel] 
	darcs patch: normal mode commands, cc, c<motion>, s, S, -, +, J, X
Message-ID: <453cec35.080c3e96.2800.36c2@mx.google.com>

Mon Oct 23 17:59:36 CEST 2006  laynor at gmail.com
  * normal mode commands, cc, c<motion>, s, S, -, +, J, X
  Added some normal mode commands:
  "cc": change the active line
  "c<motion>": change the region defined by <motion>
  "s": subst char, deletes a character like "x" and then goes to insert mode
  "S": subst line, same as "cc"
  "-": goto previous line beginning, moves the cursor to previous line at the 1st column
  "+": goto next line beginning, moves the cursor to the next line at the 1st column
  "X": deletes previous char (like backspace in insert mode, but it works in normal mode)
  "J": Joins the active line and the next line, It deserves to be fixed, because the undo is 
       broken (it popups the debugger when the command has no effect (when applied on the last line))
  
  ---- Strange Behaviors (with respect to vim) ----
  "c<motion>" 	doesnt behave the same as vim, just try it in gvim and in vial, it's faster than 
  		trying to explain it here. In particular, "cj" doesnt open a new line after deleting, 
  		and cw eats the backspace that separates words.
  ---- Broken behavior ----
  join-lines-command ("J") breaks the undo. To reproduce this behavior, just go to the last line of a file 
  and press J, and then undo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: normal-mode-commands_-cc_-c_motion__-s_-s_-__-__-j_-x.dpatch
Type: text/x-darcs-patch
Size: 7238 bytes
Desc: A darcs patch for your repository!
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061023/97cc6a2e/attachment.bin>

From brad.beveridge at gmail.com  Mon Oct 23 16:25:51 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Mon, 23 Oct 2006 09:25:51 -0700
Subject: [vial-devel] darcs patch: normal mode commands, cc, c<motion>, s,
	S, -, +, J, X
In-Reply-To: <453cec35.080c3e96.2800.36c2@mx.google.com>
References: <453cec35.080c3e96.2800.36c2@mx.google.com>
Message-ID: <de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>

On 23/10/06, laynor at gmail.com <laynor at gmail.com> wrote:
> Mon Oct 23 17:59:36 CEST 2006  laynor at gmail.com
>   * normal mode commands, cc, c<motion>, s, S, -, +, J, X
>   Added some normal mode commands:
>   "cc": change the active line
>   "c<motion>": change the region defined by <motion>
>   "s": subst char, deletes a character like "x" and then goes to insert mode
>   "S": subst line, same as "cc"
>   "-": goto previous line beginning, moves the cursor to previous line at the 1st column
>   "+": goto next line beginning, moves the cursor to the next line at the 1st column
>   "X": deletes previous char (like backspace in insert mode, but it works in normal mode)
>   "J": Joins the active line and the next line, It deserves to be fixed, because the undo is
>        broken (it popups the debugger when the command has no effect (when applied on the last line))
>
>   ---- Strange Behaviors (with respect to vim) ----
>   "c<motion>"   doesnt behave the same as vim, just try it in gvim and in vial, it's faster than
>                 trying to explain it here. In particular, "cj" doesnt open a new line after deleting,
>                 and cw eats the backspace that separates words.
>   ---- Broken behavior ----
>   join-lines-command ("J") breaks the undo. To reproduce this behavior, just go to the last line of a file
>   and press J, and then undo.

Nice!  I'll look at it tonight after work and roll it in.  I think
I'll start a couple of new files:
vim-differences.txt - a list of differences to Vim
known-bugs.txt    - known bugs in Vial

Thanks a lot for the patch!

Cheers
Brad


From brad.beveridge at gmail.com  Mon Oct 23 16:36:44 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Mon, 23 Oct 2006 09:36:44 -0700
Subject: [vial-devel] darcs patch: normal mode commands, cc, c<motion>, s,
	S, -, +, J, X
In-Reply-To: <de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>
References: <453cec35.080c3e96.2800.36c2@mx.google.com>
	<de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>
Message-ID: <de95dc6f0610230936h399a6822s6e9ac3ac141a3229@mail.gmail.com>

I've just had a quick read of the patch, here are some comments:
delete-previous-char: if you look at the primitive DELETE-CHARS
function, there is an option to delete to the left or the right of the
cursor.

It looks like we do a lot of moving the cursor by one line, lets make
a new function to advance/retreat by a line and put it in cursor.lisp.
 See this Emacs reference page for ideas for function names
http://www.cse.huji.ac.il/support/emacs/elisp-help/elisp-manref/elisp_30.html#SEC478

I don't like reusing other commands inside commands, ie in
change-region.  What we should do is create a DELETE-REGION function,
and have command-d-motion and change-region call that.  Same for
subst-char, I'd rather use the primitive (DELETE-CHARS), we may want
to change/remove COMMAND-X later.

Really good, probably I'm going to have to become more disiplined in
how I code now though :)  I can easily see myself writing exactly what
you did :)

If you want to send another patch (don't bother unrecording, just add
to it) feel free, otherwise I'll make the changes when I roll it in.

Cheers
Brad

On 23/10/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 23/10/06, laynor at gmail.com <laynor at gmail.com> wrote:
> > Mon Oct 23 17:59:36 CEST 2006  laynor at gmail.com
> >   * normal mode commands, cc, c<motion>, s, S, -, +, J, X
> >   Added some normal mode commands:
> >   "cc": change the active line
> >   "c<motion>": change the region defined by <motion>
> >   "s": subst char, deletes a character like "x" and then goes to insert mode
> >   "S": subst line, same as "cc"
> >   "-": goto previous line beginning, moves the cursor to previous line at the 1st column
> >   "+": goto next line beginning, moves the cursor to the next line at the 1st column
> >   "X": deletes previous char (like backspace in insert mode, but it works in normal mode)
> >   "J": Joins the active line and the next line, It deserves to be fixed, because the undo is
> >        broken (it popups the debugger when the command has no effect (when applied on the last line))
> >
> >   ---- Strange Behaviors (with respect to vim) ----
> >   "c<motion>"   doesnt behave the same as vim, just try it in gvim and in vial, it's faster than
> >                 trying to explain it here. In particular, "cj" doesnt open a new line after deleting,
> >                 and cw eats the backspace that separates words.
> >   ---- Broken behavior ----
> >   join-lines-command ("J") breaks the undo. To reproduce this behavior, just go to the last line of a file
> >   and press J, and then undo.
>
> Nice!  I'll look at it tonight after work and roll it in.  I think
> I'll start a couple of new files:
> vim-differences.txt - a list of differences to Vim
> known-bugs.txt    - known bugs in Vial
>
> Thanks a lot for the patch!
>
> Cheers
> Brad
>


From laynor at gmail.com  Mon Oct 23 19:13:09 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Mon, 23 Oct 2006 21:13:09 +0200
Subject: [vial-devel] darcs patch: normal mode commands, cc, c<motion>, s,
	S, -, +, J, X
In-Reply-To: <de95dc6f0610230936h399a6822s6e9ac3ac141a3229@mail.gmail.com>
References: <453cec35.080c3e96.2800.36c2@mx.google.com>
	<de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>
	<de95dc6f0610230936h399a6822s6e9ac3ac141a3229@mail.gmail.com>
Message-ID: <d0e2f05e0610231213h3d37b47x3d8cfc44549df6c3@mail.gmail.com>

On 10/23/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
>
> I've just had a quick read of the patch, here are some comments:
> delete-previous-char: if you look at the primitive DELETE-CHARS
> function, there is an option to delete to the left or the right of the
> cursor.
>
> It looks like we do a lot of moving the cursor by one line, lets make
> a new function to advance/retreat by a line and put it in cursor.lisp.
> See this Emacs reference page for ideas for function names
>
> http://www.cse.huji.ac.il/support/emacs/elisp-help/elisp-manref/elisp_30.html#SEC478
>
> I don't like reusing other commands inside commands, ie in
> change-region.  What we should do is create a DELETE-REGION function,
> and have command-d-motion and change-region call that.  Same for
> subst-char, I'd rather use the primitive (DELETE-CHARS), we may want
> to change/remove COMMAND-X later.
>
> Really good, probably I'm going to have to become more disiplined in
> how I code now though :)  I can easily see myself writing exactly what
> you did :)
>
> If you want to send another patch (don't bother unrecording, just add
> to it) feel free, otherwise I'll make the changes when I roll it in.
>
> Cheers
> Brad
>
> On 23/10/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > On 23/10/06, laynor at gmail.com < laynor at gmail.com> wrote:
> > > Mon Oct 23 17:59:36 CEST 2006  laynor at gmail.com
> > >   * normal mode commands, cc, c<motion>, s, S, -, +, J, X
> > >   Added some normal mode commands:
> > >   "cc": change the active line
> > >   "c<motion>": change the region defined by <motion>
> > >   "s": subst char, deletes a character like "x" and then goes to
> insert mode
> > >   "S": subst line, same as "cc"
> > >   "-": goto previous line beginning, moves the cursor to previous line
> at the 1st column
> > >   "+": goto next line beginning, moves the cursor to the next line at
> the 1st column
> > >   "X": deletes previous char (like backspace in insert mode, but it
> works in normal mode)
> > >   "J": Joins the active line and the next line, It deserves to be
> fixed, because the undo is
> > >        broken (it popups the debugger when the command has no effect
> (when applied on the last line))
> > >
> > >   ---- Strange Behaviors (with respect to vim) ----
> > >   "c<motion>"   doesnt behave the same as vim, just try it in gvim and
> in vial, it's faster than
> > >                 trying to explain it here. In particular, "cj" doesnt
> open a new line after deleting,
> > >                 and cw eats the backspace that separates words.
> > >   ---- Broken behavior ----
> > >   join-lines-command ("J") breaks the undo. To reproduce this
> behavior, just go to the last line of a file
> > >   and press J, and then undo.
> >
> > Nice!  I'll look at it tonight after work and roll it in.  I think
> > I'll start a couple of new files:
> > vim-differences.txt - a list of differences to Vim
> > known-bugs.txt    - known bugs in Vial
> >
> > Thanks a lot for the patch!
> >
> > Cheers
> > Brad
> >
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>
I think that reusing commands inside other commands is ugly too, I'm
correcting some of those ugly things now.
I did it to avoid code repetition though.
I also noticed that there are some patterns in the commands code that we
could try to avoid, i.e:
(defun command-function (args) body) (define-pattern ...#' command-function
...)
This one could be better expressed with a macro that outputs those two
forms, maybe something like

(define-command command-function (args)
   (body)
   (<arguments for define-pattern, without the #'command-function))

also we could then specialize this macro, to avoid the pattern
(defun command-function2 (args)
  (active-register-needs-updating)
  body)

reducing our lines of code even more, and getting rid of some patterns.
I also thought of decoupling a little the commands from the actual bindings,
defining a bunch of variables that contain the actual bindings, like
*join-lines-command-binding*, and bound them using a macro like
(define-bindings
  (*join-lines-command-binding* "J")
  (*change-single-line-from-active-binding* "cc")
  .....)
This would make changing actual bindings clearer I think. Also I think that
surely there's a better way to do something like this
than "defining a bunch of variables", but I'm a noob and now i thought
of it as a simple method =)

We also have a bunch of commands that go into insert-mode, thus creating the
pattern
(defun foo (args)
   body
   (enter-insert-mode))
so.... what about erasing this pattern too?

Let me know what do you think!
__
Alessandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/vial-devel/attachments/20061023/b2e55054/attachment.html>

From brad.beveridge at gmail.com  Mon Oct 23 20:50:13 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Mon, 23 Oct 2006 13:50:13 -0700
Subject: [vial-devel] darcs patch: normal mode commands, cc, c<motion>, s,
	S, -, +, J, X
In-Reply-To: <d0e2f05e0610231213h3d37b47x3d8cfc44549df6c3@mail.gmail.com>
References: <453cec35.080c3e96.2800.36c2@mx.google.com>
	<de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>
	<de95dc6f0610230936h399a6822s6e9ac3ac141a3229@mail.gmail.com>
	<d0e2f05e0610231213h3d37b47x3d8cfc44549df6c3@mail.gmail.com>
Message-ID: <de95dc6f0610231350h5981a650j4a01ce0fd26531a2@mail.gmail.com>

>  I think that reusing commands inside other commands is ugly too, I'm
> correcting some of those ugly things now.
> I did it to avoid code repetition though.
> I also noticed that there are some patterns in the commands code that we
> could try to avoid, i.e:
> (defun command-function (args) body) (define-pattern ...#' command-function
> ...)
> This one could be better expressed with a macro that outputs those two
> forms, maybe something like
>
> (define-command command-function (args)
>    (body)
>    (<arguments for define-pattern, without the
> #'command-function))
Once upon a time I actually did have code like that, but a lot of what
the commands do are generally useful primitive functions, such as
moving the cursor forward.  In that case the current method is
probably better because the function to call already exists.  For now
I'd like to keep it the same.  Infact, one of the things I thought
about doing was splitting key-normal, so that the (DEFINE-PATTERN ...)
forms are in a file by themselves, to make it less cluttered.

> also we could then specialize this macro, to avoid the pattern
> (defun command-function2 (args)
>   (active-register-needs-updating)
>   body)
I can't remember exactly what active-register-needs-updating does, so
that is a sign that function needs work, possible it ought to become a
macro like
(with-deletes-saved-to-active-register
  ... body ....)


> (define-bindings
>   (*join-lines-command-binding* "J")
>   (*change-single-line-from-active-binding* "cc")
>    .....)
> This would make changing actual bindings clearer I think. Also I think that
> surely there's a better way to do something like this than "defining a bunch
> of variables", but I'm a noob and now i
> thought of it as a simple method =)
Hmm, I don't understand what you mean exactly here, but just looking
at the code I don't really like the way it sits on the page :)  I'm
not sure why we need the global vars.

> We also have a bunch of commands that go into insert-mode, thus creating the
> pattern
> (defun foo (args)
>    body
>    (enter-insert-mode))
> so.... what about erasing this pattern too?
This could be worth changing, any ideas about what the new pattern
should look like?

BTW, it's nice to have somebody to chat with about Vial - please don't
think that I am being too harsh about your ideas.  I am very open to
doing things different ways, but I might need convincing sometimes :)

Cheers
Brad


From laynor at gmail.com  Mon Oct 23 21:13:02 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Mon, 23 Oct 2006 23:13:02 +0200
Subject: [vial-devel] darcs patch: normal mode commands, cc, c<motion>, s,
	S, -, +, J, X
In-Reply-To: <de95dc6f0610231350h5981a650j4a01ce0fd26531a2@mail.gmail.com>
References: <453cec35.080c3e96.2800.36c2@mx.google.com>
	<de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>
	<de95dc6f0610230936h399a6822s6e9ac3ac141a3229@mail.gmail.com>
	<d0e2f05e0610231213h3d37b47x3d8cfc44549df6c3@mail.gmail.com>
	<de95dc6f0610231350h5981a650j4a01ce0fd26531a2@mail.gmail.com>
Message-ID: <d0e2f05e0610231413h5af47b5cl11ccf2a26d947e4d@mail.gmail.com>

> > (define-bindings
> >   (*join-lines-command-binding* "J")
> >   (*change-single-line-from-active-binding* "cc")
> >    .....)
> > This would make changing actual bindings clearer I think. Also I think that
> > surely there's a better way to do something like this than "defining a bunch
> > of variables", but I'm a noob and now i
> > thought of it as a simple method =)
> Hmm, I don't understand what you mean exactly here, but just looking
> at the code I don't really like the way it sits on the page :)  I'm
> not sure why we need the global vars.

The thing I thought is about making it easier for the (end) user to
change some bindings. I guess there's a better way to do it than
global variables, maybe putting the bindings in a hash table or
something like that...
Doing so the end user can modify the bindings (or add new ones)  just
putting (*<name--of-the-command>-bindings* "hk") inside the define
bindings form instead of having to deal with define-pattern forms
(that are also repeated thru all the code, so making a macro is not a
bad thing I think).

> > We also have a bunch of commands that go into insert-mode, thus creating the
> > pattern
> > (defun foo (args)
> >    body
> >    (enter-insert-mode))
> > so.... what about erasing this pattern too?
> This could be worth changing, any ideas about what the new pattern
> should look like?
I thought of a macro that could look like
(define-insert-command foo(args)
    body)
that expands to the pattern I highlighted above :)

> BTW, it's nice to have somebody to chat with about Vial - please don't
> think that I am being too harsh about your ideas.  I am very open to
> doing things different ways, but I might need convincing sometimes :)
>

Don't worry, I know how it feels when someone wants to change things
:) I'll try to explain my ideas better on irc!
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>

Ciao,
__
Alessandro


From brad.beveridge at gmail.com  Mon Oct 23 21:19:39 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Mon, 23 Oct 2006 14:19:39 -0700
Subject: [vial-devel] darcs patch: normal mode commands, cc, c<motion>, s,
	S, -, +, J, X
In-Reply-To: <d0e2f05e0610231413h5af47b5cl11ccf2a26d947e4d@mail.gmail.com>
References: <453cec35.080c3e96.2800.36c2@mx.google.com>
	<de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>
	<de95dc6f0610230936h399a6822s6e9ac3ac141a3229@mail.gmail.com>
	<d0e2f05e0610231213h3d37b47x3d8cfc44549df6c3@mail.gmail.com>
	<de95dc6f0610231350h5981a650j4a01ce0fd26531a2@mail.gmail.com>
	<d0e2f05e0610231413h5af47b5cl11ccf2a26d947e4d@mail.gmail.com>
Message-ID: <de95dc6f0610231419m34511dd5hcf4c879751ff0d54@mail.gmail.com>

On 23/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > (define-bindings
> > >   (*join-lines-command-binding* "J")
> > >   (*change-single-line-from-active-binding* "cc")
> > >    .....)
> > > This would make changing actual bindings clearer I think. Also I think that
> > > surely there's a better way to do something like this than "defining a bunch
> > > of variables", but I'm a noob and now i
> > > thought of it as a simple method =)
> > Hmm, I don't understand what you mean exactly here, but just looking
> > at the code I don't really like the way it sits on the page :)  I'm
> > not sure why we need the global vars.
>
> The thing I thought is about making it easier for the (end) user to
> change some bindings. I guess there's a better way to do it than
> global variables, maybe putting the bindings in a hash table or
> something like that...
> Doing so the end user can modify the bindings (or add new ones)  just
> putting (*<name--of-the-command>-bindings* "hk") inside the define
> bindings form instead of having to deal with define-pattern forms
> (that are also repeated thru all the code, so making a macro is not a
> bad thing I think).
Ah, I see what you mean.  I think one of the strongest points of Vim
is that there is a fairly standard key map that people generally don't
deviate from.  For example, I type Dvorak and have only changed the
home row movement keys jkhl to htjk.  h and t for up and down, j and k
for left and right.  Vial currently supports this kind of remapping
(the same as Vim's :map command), so that you can map any single
keypress to any other single keypress, or in fact a single keypress to
multiple keypresses, ie "D" -> "dd" perhaps.
I think this level of remapping is probably sufficient.  The
DEFINE-PATTERN macro is not really meant to be used by end users, only
for adding the default mappings.
Does that make sense?

Cheers
Brad


From laynor at gmail.com  Mon Oct 23 22:14:45 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Tue, 24 Oct 2006 00:14:45 +0200
Subject: [vial-devel] darcs patch: normal mode commands, cc, c<motion>, s,
	S, -, +, J, X
In-Reply-To: <de95dc6f0610231419m34511dd5hcf4c879751ff0d54@mail.gmail.com>
References: <453cec35.080c3e96.2800.36c2@mx.google.com>
	<de95dc6f0610230925r602b0c84s4ff820379b23e3db@mail.gmail.com>
	<de95dc6f0610230936h399a6822s6e9ac3ac141a3229@mail.gmail.com>
	<d0e2f05e0610231213h3d37b47x3d8cfc44549df6c3@mail.gmail.com>
	<de95dc6f0610231350h5981a650j4a01ce0fd26531a2@mail.gmail.com>
	<d0e2f05e0610231413h5af47b5cl11ccf2a26d947e4d@mail.gmail.com>
	<de95dc6f0610231419m34511dd5hcf4c879751ff0d54@mail.gmail.com>
Message-ID: <d0e2f05e0610231514y5e28203fma658ccd9f0ee7a07@mail.gmail.com>

On 10/23/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 23/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > > (define-bindings
> > > >   (*join-lines-command-binding* "J")
> > > >   (*change-single-line-from-active-binding* "cc")
> > > >    .....)
> > > > This would make changing actual bindings clearer I think. Also I think that
> > > > surely there's a better way to do something like this than "defining a bunch
> > > > of variables", but I'm a noob and now i
> > > > thought of it as a simple method =)
> > > Hmm, I don't understand what you mean exactly here, but just looking
> > > at the code I don't really like the way it sits on the page :)  I'm
> > > not sure why we need the global vars.
> >
> > The thing I thought is about making it easier for the (end) user to
> > change some bindings. I guess there's a better way to do it than
> > global variables, maybe putting the bindings in a hash table or
> > something like that...
> > Doing so the end user can modify the bindings (or add new ones)  just
> > putting (*<name--of-the-command>-bindings* "hk") inside the define
> > bindings form instead of having to deal with define-pattern forms
> > (that are also repeated thru all the code, so making a macro is not a
> > bad thing I think).
> Ah, I see what you mean.  I think one of the strongest points of Vim
> is that there is a fairly standard key map that people generally don't
> deviate from.  For example, I type Dvorak and have only changed the
> home row movement keys jkhl to htjk.  h and t for up and down, j and k
> for left and right.  Vial currently supports this kind of remapping
> (the same as Vim's :map command), so that you can map any single
> keypress to any other single keypress, or in fact a single keypress to
> multiple keypresses, ie "D" -> "dd" perhaps.
> I think this level of remapping is probably sufficient.  The
> DEFINE-PATTERN macro is not really meant to be used by end users, only
> for adding the default mappings.
> Does that make sense?
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>

Yeah, I forgot that way to remap, cause i saw it only once when
commenting out your dvorak mappings =) I also guess that the kind of
remapping vial offers is enough, so forget the proposal :)
 I have just a question about it that I'll make in irc.
__
Alessandro


From brad.beveridge at gmail.com  Mon Oct 23 23:33:17 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Mon, 23 Oct 2006 16:33:17 -0700
Subject: [vial-devel] Flexichain and Cursorchain
Message-ID: <de95dc6f0610231633t407e1399u560191819e88fa8f@mail.gmail.com>

If it's not nailed down, steal it.  That's my motto.  Vial originally
started life as a fun way to learn Common Lisp, which meant doing some
stuff myself that maybe I shouldn't have.
Particularly the buffer stuff.
It might be worthwhile moving to Flexichain
(http://common-lisp.net/project/flexichain/), which is the underlying
implementation that Climacs uses for buffer management.

I'm going to look at it harder tonight, and if I do decide to change
then it will probably mean big changes for Vial's internal code - but
probably changes that clean the code up quite a bit.
If we do move to flexichain, the first step will be to abstract out
all the code that currently plays with the internals of buffer or
cursor objects, then re-implement those functions using Flexichain.

Thoughts?

Cheers
Brad


From brad.beveridge at gmail.com  Tue Oct 24 04:55:49 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Mon, 23 Oct 2006 21:55:49 -0700
Subject: [vial-devel] Re: Flexichain and Cursorchain
In-Reply-To: <de95dc6f0610231633t407e1399u560191819e88fa8f@mail.gmail.com>
References: <de95dc6f0610231633t407e1399u560191819e88fa8f@mail.gmail.com>
Message-ID: <de95dc6f0610232155h3ee0daa0i32985c4a86e6d8a6@mail.gmail.com>

On 23/10/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> If it's not nailed down, steal it.  That's my motto.  Vial originally
> started life as a fun way to learn Common Lisp, which meant doing some
> stuff myself that maybe I shouldn't have.
> Particularly the buffer stuff.
> It might be worthwhile moving to Flexichain
> (http://common-lisp.net/project/flexichain/), which is the underlying
> implementation that Climacs uses for buffer management.
>
> I'm going to look at it harder tonight, and if I do decide to change
> then it will probably mean big changes for Vial's internal code - but
> probably changes that clean the code up quite a bit.
> If we do move to flexichain, the first step will be to abstract out
> all the code that currently plays with the internals of buffer or
> cursor objects, then re-implement those functions using Flexichain.
>
> Thoughts?
>
> Cheers
> Brad
>
I've looked at Flexichain tonight.  It is a good idea, and worth
moving to.  However I want to get something done, and changing out the
buffer, cursor and undo system is a good chunk of work.  So
Flexichains are not going to happen anytime soon.  However, we will
start tightening up abstraction.  Right now lots of modules directly
use the internal bits of various classes, that is going to stop.  The
next few changes I make will probably be with cleaning up intermodule
interfaces.

Cheers
Brad


From brad.beveridge at gmail.com  Tue Oct 24 14:49:22 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Tue, 24 Oct 2006 07:49:22 -0700
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240233q1efec587xfbcdd31b4dd79fca@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
Message-ID: <de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>

On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> On 10/24/06, Alessandro Piras <laynor at gmail.com> wrote:
> > On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > Pretty much all the functions in buffer.lisp and cursor.lisp will be
> > > preserved with the same semantics.  Any place that directly references
> > > lines-of buffer/cursor will need to change.
> > > I'll make changes to remove any and all references to those buffer or
> > > cursor members.
> > > So, feel free to do what you like, but please:
> > > Don't mess too much with cursor.lisp or buffer.lisp,
> > > don't directly access (lines-of cursor) or (lines-of buffer)
> > > Thanks :)
> > >
> > > Cheers
> > > Brad
> > >
> >
> > Ok, I'll keep working on commands and things. Though It would be a
> > good thing defining a more abstract interface for buffers, a sort of
> > "layer" that could be hacked inside that would be useful to:
> >
> > 1) handling some bugs of buffer implementation(s) we('ll) use
> > 2) Isolate theese hacks to a place
> > 3) Stabilizing a "language" used to write commands so they're
> > independent from the internals.
> > 4) Minimize the changes needed when internals have to change for some
> > reasons (we should only fix/modify the layer code, that's used from
> > many commands)
> >
> > When the buffer becomes stable, and it works well, we can tighten up
> > the interface, keeping commands' code the same,
> >
> > Tell me how does it sound :)
That sounds really good.  And I think that we already have the API
layed out - Emacs' internal API is actually really good :
http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_toc.html
Trying to emulate the Emacs API has a few advantages
1) Don't need to invent a text-editing API
2) Already have good documentation, as long as we follow the behaviour
3) Low barrier to entry for people already familiar with that API.

> I forgot to say, we need also another type of command, different from
> motion, op or op-motion. With those three types it's hard (if
> possible) to code commands like "r", which is used a lot (it replace
> the char under the cursor with another, without entering insert mode),
> that take a character as an argument.
> Actually there are only a few commands that work that way (I only know
> of 3, "r" "f" "F"), but given the importance of replace-char it should
> be worth having a way to define them. also, maybe it's good if you're
> going to touch the buffer code, to think about a good interface for
> text replacing, so we could have a better implementation than
> removing/inserting the char, that maybe just does actual overwriting
> of text.
I decided that this should go to the list, for archive purposes.  Hope
you don't mind :)
You're right about the "r" command.  We should find all those
"special" cases, and make sure we can handle them.  "r" is something I
haven't considered yet, and I've been putting off replace mode :)

> Another thing to think about is a little annoyance in the
> current undo system. It works well, but some times not in the
> predictable way... I'll explain this to you better showing the cases I
> discovered, because it's better seeing than trying to figure it out
> from an explanation. The undo system we have just needs a few things
> more to work the way one would think, that are operation-grouping and
> cursor position saving.
> The good thing is that it can be easily (i guess) built on top of the
> current undo system. It would work this way:
>
> let's say we have a command that executes 3 basic operations (the J
> command is an example)
>
> op1
> op2
> op3
>
> we just need to wrap those in a group.
> also, we need to remember the cursor position before the command, so
> the thing we have to save is actually
There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
of undos.  The saving of the cursor shouldn't be required - if you
think about it, when you undo/redo you are playing back or unplaying
keystrokes.  If you are undoing an insert of "hello there", you should
delete 11 chars, and the point should be back before you inserted any
text.

>
<SNIP>
> Tell me what do you think :)
>
I like it.  I think that right now I would like it most if you thought
about issues like the "r" command, if we can get a framework that
covers all those cases it will be really good in the long run.  Even
though I just posted saying "let's not move to Flexichain right now",
I'm leaning that way again.  I'll write up my thoughts to the list,
but it basically boils down to the fact that being able to treat the
buffer as a giant string has many advantages over the list of lines
approach.
The problem with changing out buffers right now is that we make lots
of assumptions about the list of lines structure.  We basically need
to change:
buffer, cursor, register, search, colours, autocomplete, mode-lisp,
regions, view, ncurses-io, undo
But, each module will benefit greatly from being able to treate the
buffer as a big string.
Guess I have a lot of work ahead :)

Cheers
Brad


From laynor at gmail.com  Tue Oct 24 15:56:32 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Tue, 24 Oct 2006 17:56:32 +0200
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240233q1efec587xfbcdd31b4dd79fca@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
	<de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>
	<d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
Message-ID: <d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>

---------- Forwarded message ----------
From: Alessandro Piras <laynor at gmail.com>
Date: Oct 24, 2006 5:41 PM
Subject: Re: What will break with flexichain
To: Brad Beveridge <brad.beveridge at gmail.com>


On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> ....
> There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> of undos.  The saving of the cursor shouldn't be required - if you
> think about it, when you undo/redo you are playing back or unplaying
> keystrokes.  If you are undoing an insert of "hello there", you should
> delete 11 chars, and the point should be back before you inserted any
> text.

It works in most cases but in some don't...
try theese things:
insert "abcdefgh"
move to the "d" letter
delete "d" and "e" using the "x" command
now undo the changes, you'll see the cursor going to the end of the
line. instead of where it was before applying the x command.

The same behavior presents when you insert text between words, let's
say you have this line

pino pigna

you move the cursor between the 2 words, insert
" is", go to normal mode and press u to undo. The cursor will go at
the end of the line.

Same thing for the "c<motion>" command and such.
Good to know that there is already the macro for undo undo grouping !




> >
> <SNIP>
> > Tell me what do you think :)
> >
> I like it.  I think that right now I would like it most if you thought
> about issues like the "r" command, if we can get a framework that
> covers all those cases it will be really good in the long run.
I'll take a look to define pattern and think about a way to include
all forms of vim commands, maybe those like d3d too :)
I just hope it wont be too hard for a noob like me ^^

>Even
> though I just posted saying "let's not move to Flexichain right now",
> I'm leaning that way again.  I'll write up my thoughts to the list,
> but it basically boils down to the fact that being able to treat the
> buffer as a giant string has many advantages over the list of lines
> approach.
> The problem with changing out buffers right now is that we make lots
> of assumptions about the list of lines structure.  We basically need
> to change:
> buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> regions, view, ncurses-io, undo
> But, each module will benefit greatly from being able to treate the
> buffer as a big string.
> Guess I have a lot of work ahead :)
>
> Cheers
> Brad
>
I thought you wanted to use a buffer made of a list of flexichains
(gap buffers), not just one gap buffer to handle our buffer..
reading the flexichains docs it seems that it's better to use a list
or a sequence of gap buffers rather than a big gap buffer.. In terms
of performance it seems. I don't know wich are the great benefits that
you are talking about though, so it could be that it's better having a
little less performance and a clerarer code, at least now :)

I think that we should put an abstraction layer also there, between
the buffer module and all those modules that now depend on the
implementation (the ones you listed above) ,if it makes sence, maybe
one day we'll want to change the buffer implementation again, and it
would be good not to change those modules again.

Tell me what you think, and if it is feasible to put an abstraction
layer also there :)

I forgot to say, I find the idea of using the emacs api a really good
one! Going to have a look at it soon.
__
Alessandro


From brad.beveridge at gmail.com  Tue Oct 24 16:57:34 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Tue, 24 Oct 2006 09:57:34 -0700
Subject: [vial-devel] Re: Flexichain and Cursorchain
In-Reply-To: <de95dc6f0610232155h3ee0daa0i32985c4a86e6d8a6@mail.gmail.com>
References: <de95dc6f0610231633t407e1399u560191819e88fa8f@mail.gmail.com>
	<de95dc6f0610232155h3ee0daa0i32985c4a86e6d8a6@mail.gmail.com>
Message-ID: <de95dc6f0610240957p40930121g1eef7fa3b53e6eed@mail.gmail.com>

On 23/10/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 23/10/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > If it's not nailed down, steal it.  That's my motto.  Vial originally
> > started life as a fun way to learn Common Lisp, which meant doing some
> > stuff myself that maybe I shouldn't have.
> > Particularly the buffer stuff.
> > It might be worthwhile moving to Flexichain
> > (http://common-lisp.net/project/flexichain/), which is the underlying
> > implementation that Climacs uses for buffer management.
> >
> > I'm going to look at it harder tonight, and if I do decide to change
> > then it will probably mean big changes for Vial's internal code - but
> > probably changes that clean the code up quite a bit.
> > If we do move to flexichain, the first step will be to abstract out
> > all the code that currently plays with the internals of buffer or
> > cursor objects, then re-implement those functions using Flexichain.
> >
> > Thoughts?
> >
> > Cheers
> > Brad
> >
> I've looked at Flexichain tonight.  It is a good idea, and worth
> moving to.  However I want to get something done, and changing out the
> buffer, cursor and undo system is a good chunk of work.  So
> Flexichains are not going to happen anytime soon.  However, we will
> start tightening up abstraction.  Right now lots of modules directly
> use the internal bits of various classes, that is going to stop.  The
> next few changes I make will probably be with cleaning up intermodule
> interfaces.
>
> Cheers
> Brad
>
Flexichain is a buffer API used by Climacs and refactored into a
library.  Flexichain provides CLOS classes and generic methods that
abstract a sequence that has insert/delete/get functions.
Cursorchain provides the concept of a point or mark into a Flexichain,
with the semantics that you may insert or delete at the cursor.  It
also moves cursors so that they maintain their position when text is
inserted or deleted.
Flexi* also provides an implementation for the protocol in the form of
a circular gap buffer.  It is obvious that we could wrap our own List
of lines method with Flexi* protocols, so I will just discuss the
advantages/disadvantages of a gap buffer implementation and a list of
lines implementation.
Note - flexichains only provides for accessing single elements in an
abstract way, but if you wish to write implementation specific code
you can make performance improvements.

The main slow operations in a gap buffer are
1) Moving the gap
2) Moving by lines as the protocol does not know about lines.

I timed 1 & 2 on Clisp on a 2Ghz Pentium-M: a middle of the road CPU
and the slowest Lisp.  I didn't actually use Flexichains, but did the
kind of operations it would need to do.
Moving the gap for a 1Mb buffer takes ~0.3 of a second.  Scanning a
1Mb buffer for the whole length of the buffer takes ~0.5 of a second.
This I think is absolute worst case behaviour, on a compiled Lisp, on
a decent machine, on a reglar sized file (even on a big 300K file)
these operations will take no time at all.
I have no idea how a LineList implementation would stack up, but I
suspect it would be slightly worse for scanning for chars.
LL = List of lines
FC = Flexichain

Random Access:
 * FC lets you treat the whole buffer as an array, providing O(1) access.
 * LL is worst case O(n), though average case can be better. (N = num
lines in buffer)

Sequential Access:
 * Both are O(1).
 * LL is O(n) for the first access (N = num lines in buffer)

Moving by Line:
 * LL is O(1)
 * FC is O(n) (N = chars in line)
   * Note, here N is small (< 100) and moving by char is VERY fast

Moving to specific line:
 * LL is O(n)   (N = line to move to)
 * FC is O(n*m) (N = line to move to, M = average chars per line)
   * Note, here M is small (< 100) and moving by char is VERY fast

Converting buffer to a string (read only access):
 * FC is O((n*m)/2), it needs to simply move the gap to the end of the
buffer, a very fast and non-consing operation.  (N = line to move to,
M = average chars per line)
 * LL is O(n), but must make an entire copy of the buffer, consing
horribly.  (N = number of lines in buffer)
 ** FC is the CLEAR winner here **

Converting part of a buffer to a read only string:
 * Both are O(n), where N is chars in the destination string.
 * FC moves the gap and won't need to cons.
   * It may be better to cons up a new string rather than move the gap.
   * You will only need to move the gap to just before or after the
sequence you are taking out.
   * The gap will need to move back when you continue editing.
 * LL will need to cons for any string that spans lines.

Converting part of a buffer to a new string:
 * Both about O(n) + book keeping.  N is chars in the destination
string.  Consing the new string is the biggest issue.

Sequential inserting into buffer:
 * Both are O(1), plus book keeping (move the gap, or find the line first)

Marks:
 * A clever mark implementation for LL will have no cost for marks
when doing ops.
 * FC will be O(n) every time the gap buffer is moved.  (N = number of
marks to move)

Use cases:
 All in all, both methods are similar orders of magnitude in most
operations, you could pick either and be satisifed with performance
for most operations.
The only clear difference in operations is converting to read only
strings, and only then when the read-only string involves large
sections of the buffer.
So, at what times would we like to deal with large strings?
Saving:
 * LL, needs to loop over lines and use WRITE-LINE
 * FC, move the gap and save the array in one call

Searching the whole buffer:
 * LL, needs to loop over lines
 * FC, move the gap, one call to CL-PPCRE
 * FC will be much easier for multiline search strings
 * On text changing (active highlighting):
  * much the same for both, need to rescan the text as a string
  * LL, always keeps the line as a plain string, just pass it to CL-PPCRE
  * FC, need to reconstruct the line: move gap to end of line, pass to
CL-PPCRE, move gap back
  * Neither matters that much, it is happening at human speed - so
just whatever works.

Coping from one buffer/register to another:
 * FC, move the gap and do a single call to string copy
 * LL, loop over lines, copying to new buffer
 * FC is easier for partial lines - it has no concept of lines.
 * LL needs to do fiddly work at the start/end of a region to copy
partial lines.

Partial lines:
 * FC has no concept of lines, so there is no special handling of
"lines" you just copy chars around.
 * LL has "lines" ingrained in it.  Any time you want to access text,
you need to
  * consider you may only want to deal with a partial line
  * account for moving over line chars and do something special

Conclusion:
I think that using FC makes for a simpler system, that may have
performance gains and will certainly not have large performance
losses.
I now believe that switching to Flexichains is a prudent move.
Unfortuantly, it will mean a re-write of perhaps 70% of Vial, but that
70% should shrink significantly.  About the only thing that can stay
is the command handling and ncurses input layer.  I will write up a
plan on how to move to FC soon.

Thoughts?

Cheers
Brad


From laynor at gmail.com  Tue Oct 24 21:21:25 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Tue, 24 Oct 2006 23:21:25 +0200
Subject: [vial-devel] Re: Flexichain and Cursorchain
In-Reply-To: <de95dc6f0610240957p40930121g1eef7fa3b53e6eed@mail.gmail.com>
References: <de95dc6f0610231633t407e1399u560191819e88fa8f@mail.gmail.com>
	<de95dc6f0610232155h3ee0daa0i32985c4a86e6d8a6@mail.gmail.com>
	<de95dc6f0610240957p40930121g1eef7fa3b53e6eed@mail.gmail.com>
Message-ID: <d0e2f05e0610241421r7fd8f7fj5242aea62d68bfda@mail.gmail.com>

On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 23/10/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > On 23/10/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > If it's not nailed down, steal it.  That's my motto.  Vial originally
> > > started life as a fun way to learn Common Lisp, which meant doing some
> > > stuff myself that maybe I shouldn't have.
> > > Particularly the buffer stuff.
> > > It might be worthwhile moving to Flexichain
> > > (http://common-lisp.net/project/flexichain/), which is the underlying
> > > implementation that Climacs uses for buffer management.
> > >
> > > I'm going to look at it harder tonight, and if I do decide to change
> > > then it will probably mean big changes for Vial's internal code - but
> > > probably changes that clean the code up quite a bit.
> > > If we do move to flexichain, the first step will be to abstract out
> > > all the code that currently plays with the internals of buffer or
> > > cursor objects, then re-implement those functions using Flexichain.
> > >
> > > Thoughts?
> > >
> > > Cheers
> > > Brad
> > >
> > I've looked at Flexichain tonight.  It is a good idea, and worth
> > moving to.  However I want to get something done, and changing out the
> > buffer, cursor and undo system is a good chunk of work.  So
> > Flexichains are not going to happen anytime soon.  However, we will
> > start tightening up abstraction.  Right now lots of modules directly
> > use the internal bits of various classes, that is going to stop.  The
> > next few changes I make will probably be with cleaning up intermodule
> > interfaces.
> >
> > Cheers
> > Brad
> >
> Flexichain is a buffer API used by Climacs and refactored into a
> library.  Flexichain provides CLOS classes and generic methods that
> abstract a sequence that has insert/delete/get functions.
> Cursorchain provides the concept of a point or mark into a Flexichain,
> with the semantics that you may insert or delete at the cursor.  It
> also moves cursors so that they maintain their position when text is
> inserted or deleted.
> Flexi* also provides an implementation for the protocol in the form of
> a circular gap buffer.  It is obvious that we could wrap our own List
> of lines method with Flexi* protocols, so I will just discuss the
> advantages/disadvantages of a gap buffer implementation and a list of
> lines implementation.
> Note - flexichains only provides for accessing single elements in an
> abstract way, but if you wish to write implementation specific code
> you can make performance improvements.
>
> The main slow operations in a gap buffer are
> 1) Moving the gap
> 2) Moving by lines as the protocol does not know about lines.
>
> I timed 1 & 2 on Clisp on a 2Ghz Pentium-M: a middle of the road CPU
> and the slowest Lisp.  I didn't actually use Flexichains, but did the
> kind of operations it would need to do.
> Moving the gap for a 1Mb buffer takes ~0.3 of a second.  Scanning a
> 1Mb buffer for the whole length of the buffer takes ~0.5 of a second.
> This I think is absolute worst case behaviour, on a compiled Lisp, on
> a decent machine, on a reglar sized file (even on a big 300K file)
> these operations will take no time at all.
> I have no idea how a LineList implementation would stack up, but I
> suspect it would be slightly worse for scanning for chars.
> LL = List of lines
> FC = Flexichain
>
> Random Access:
>  * FC lets you treat the whole buffer as an array, providing O(1) access.
>  * LL is worst case O(n), though average case can be better. (N = num
> lines in buffer)
>
> Sequential Access:
>  * Both are O(1).
>  * LL is O(n) for the first access (N = num lines in buffer)
>
> Moving by Line:
>  * LL is O(1)
>  * FC is O(n) (N = chars in line)
>    * Note, here N is small (< 100) and moving by char is VERY fast
>
> Moving to specific line:
>  * LL is O(n)   (N = line to move to)
>  * FC is O(n*m) (N = line to move to, M = average chars per line)
>    * Note, here M is small (< 100) and moving by char is VERY fast
>
> Converting buffer to a string (read only access):
>  * FC is O((n*m)/2), it needs to simply move the gap to the end of the
> buffer, a very fast and non-consing operation.  (N = line to move to,
> M = average chars per line)
>  * LL is O(n), but must make an entire copy of the buffer, consing
> horribly.  (N = number of lines in buffer)
>  ** FC is the CLEAR winner here **
>
> Converting part of a buffer to a read only string:
>  * Both are O(n), where N is chars in the destination string.
>  * FC moves the gap and won't need to cons.
>    * It may be better to cons up a new string rather than move the gap.
>    * You will only need to move the gap to just before or after the
> sequence you are taking out.
>    * The gap will need to move back when you continue editing.
>  * LL will need to cons for any string that spans lines.
>
> Converting part of a buffer to a new string:
>  * Both about O(n) + book keeping.  N is chars in the destination
> string.  Consing the new string is the biggest issue.
>
> Sequential inserting into buffer:
>  * Both are O(1), plus book keeping (move the gap, or find the line first)
>
> Marks:
>  * A clever mark implementation for LL will have no cost for marks
> when doing ops.
>  * FC will be O(n) every time the gap buffer is moved.  (N = number of
> marks to move)
>
> Use cases:
>  All in all, both methods are similar orders of magnitude in most
> operations, you could pick either and be satisifed with performance
> for most operations.
> The only clear difference in operations is converting to read only
> strings, and only then when the read-only string involves large
> sections of the buffer.
> So, at what times would we like to deal with large strings?
> Saving:
>  * LL, needs to loop over lines and use WRITE-LINE
>  * FC, move the gap and save the array in one call
>
> Searching the whole buffer:
>  * LL, needs to loop over lines
>  * FC, move the gap, one call to CL-PPCRE
>  * FC will be much easier for multiline search strings
>  * On text changing (active highlighting):
>   * much the same for both, need to rescan the text as a string
>   * LL, always keeps the line as a plain string, just pass it to CL-PPCRE
>   * FC, need to reconstruct the line: move gap to end of line, pass to
> CL-PPCRE, move gap back
>   * Neither matters that much, it is happening at human speed - so
> just whatever works.
>
> Coping from one buffer/register to another:
>  * FC, move the gap and do a single call to string copy
>  * LL, loop over lines, copying to new buffer
>  * FC is easier for partial lines - it has no concept of lines.
>  * LL needs to do fiddly work at the start/end of a region to copy
> partial lines.
>
> Partial lines:
>  * FC has no concept of lines, so there is no special handling of
> "lines" you just copy chars around.
>  * LL has "lines" ingrained in it.  Any time you want to access text,
> you need to
>   * consider you may only want to deal with a partial line
>   * account for moving over line chars and do something special
>
> Conclusion:
> I think that using FC makes for a simpler system, that may have
> performance gains and will certainly not have large performance
> losses.
> I now believe that switching to Flexichains is a prudent move.
> Unfortuantly, it will mean a re-write of perhaps 70% of Vial, but that
> 70% should shrink significantly.  About the only thing that can stay
> is the command handling and ncurses input layer.  I will write up a
> plan on how to move to FC soon.
>
> Thoughts?
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>

I tried out climacs a little, It's not pretty flash, but It could be
because of clim too, don't know... emacs seems a lot faster, at a
first view.
Anyway, i read that emacs uses one big gap buffer to represent the
entire text buffer, and gnu emacs performance seems enough (when it
comes only to text editing, without considering the long
initialization it needs (and they say that it's something wrong with
debian setups, I recently updated and now emacs has a really fast
startup, like a fraction of second, and not the old 8 seconds...
lol)).

So let's go for the simpler system!


From brad.beveridge at gmail.com  Wed Oct 25 05:51:30 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Tue, 24 Oct 2006 22:51:30 -0700
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240233q1efec587xfbcdd31b4dd79fca@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
	<de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>
	<d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
	<d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>
Message-ID: <de95dc6f0610242251p3541c0d8maf6f584929eafda0@mail.gmail.com>

On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Alessandro Piras <laynor at gmail.com>
> Date: Oct 24, 2006 5:41 PM
> Subject: Re: What will break with flexichain
> To: Brad Beveridge <brad.beveridge at gmail.com>
>
>
> On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > ....
> > There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> > of undos.  The saving of the cursor shouldn't be required - if you
> > think about it, when you undo/redo you are playing back or unplaying
> > keystrokes.  If you are undoing an insert of "hello there", you should
> > delete 11 chars, and the point should be back before you inserted any
> > text.
>
> It works in most cases but in some don't...
> try theese things:
> insert "abcdefgh"
> move to the "d" letter
> delete "d" and "e" using the "x" command
> now undo the changes, you'll see the cursor going to the end of the
> line. instead of where it was before applying the x command.
>
> The same behavior presents when you insert text between words, let's
> say you have this line
>
> pino pigna
>
> you move the cursor between the 2 words, insert
> " is", go to normal mode and press u to undo. The cursor will go at
> the end of the line.
>
> Same thing for the "c<motion>" command and such.
> Good to know that there is already the macro for undo undo grouping !
>
>
>
>
> > >
> > <SNIP>
> > > Tell me what do you think :)
> > >
> > I like it.  I think that right now I would like it most if you thought
> > about issues like the "r" command, if we can get a framework that
> > covers all those cases it will be really good in the long run.
> I'll take a look to define pattern and think about a way to include
> all forms of vim commands, maybe those like d3d too :)
> I just hope it wont be too hard for a noob like me ^^
>
> >Even
> > though I just posted saying "let's not move to Flexichain right now",
> > I'm leaning that way again.  I'll write up my thoughts to the list,
> > but it basically boils down to the fact that being able to treat the
> > buffer as a giant string has many advantages over the list of lines
> > approach.
> > The problem with changing out buffers right now is that we make lots
> > of assumptions about the list of lines structure.  We basically need
> > to change:
> > buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> > regions, view, ncurses-io, undo
> > But, each module will benefit greatly from being able to treate the
> > buffer as a big string.
> > Guess I have a lot of work ahead :)
> >
> > Cheers
> > Brad
> >
> I thought you wanted to use a buffer made of a list of flexichains
> (gap buffers), not just one gap buffer to handle our buffer..
> reading the flexichains docs it seems that it's better to use a list
> or a sequence of gap buffers rather than a big gap buffer.. In terms
> of performance it seems. I don't know wich are the great benefits that
> you are talking about though, so it could be that it's better having a
> little less performance and a clerarer code, at least now :)
>
> I think that we should put an abstraction layer also there, between
> the buffer module and all those modules that now depend on the
> implementation (the ones you listed above) ,if it makes sence, maybe
> one day we'll want to change the buffer implementation again, and it
> would be good not to change those modules again.
>
> Tell me what you think, and if it is feasible to put an abstraction
> layer also there :)
>
> I forgot to say, I find the idea of using the emacs api a really good
> one! Going to have a look at it soon.
> __

Continuing with the "steal it" motif, I am thinking about stealing
even more from Climacs.  The plan as it stands is to try and use
Climacs files wholesale, including the buffer protocol, the undo
protocol, etc.
I don't fully know how to do it yet, but at least for a while you will
probably need a Climacs code tree hanging around.
http://www.cliki.net/Climacs
dept-info.labri.fr/~strandh/climacs-internals.pdf
dept-info.labri.fr/~strandh/climacs-user.pdf

Basically the only parts of Vial that we can keep are the key
handling.  This is probably almost a total rewrite.
Sorry to have announced Vial and then immediately take a different
tack.  If truth be told, I should have done this before I publicly
announced - but it took going public for a third party to hit me with
a cluestick.

Cheers
Brad


From laynor at gmail.com  Wed Oct 25 09:36:41 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Wed, 25 Oct 2006 11:36:41 +0200
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <de95dc6f0610242251p3541c0d8maf6f584929eafda0@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240233q1efec587xfbcdd31b4dd79fca@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
	<de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>
	<d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
	<d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>
	<de95dc6f0610242251p3541c0d8maf6f584929eafda0@mail.gmail.com>
Message-ID: <d0e2f05e0610250236p11b480f9m7ea545f0601c1b05@mail.gmail.com>

On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > ---------- Forwarded message ----------
> > From: Alessandro Piras <laynor at gmail.com>
> > Date: Oct 24, 2006 5:41 PM
> > Subject: Re: What will break with flexichain
> > To: Brad Beveridge <brad.beveridge at gmail.com>
> >
> >
> > On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > ....
> > > There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> > > of undos.  The saving of the cursor shouldn't be required - if you
> > > think about it, when you undo/redo you are playing back or unplaying
> > > keystrokes.  If you are undoing an insert of "hello there", you should
> > > delete 11 chars, and the point should be back before you inserted any
> > > text.
> >
> > It works in most cases but in some don't...
> > try theese things:
> > insert "abcdefgh"
> > move to the "d" letter
> > delete "d" and "e" using the "x" command
> > now undo the changes, you'll see the cursor going to the end of the
> > line. instead of where it was before applying the x command.
> >
> > The same behavior presents when you insert text between words, let's
> > say you have this line
> >
> > pino pigna
> >
> > you move the cursor between the 2 words, insert
> > " is", go to normal mode and press u to undo. The cursor will go at
> > the end of the line.
> >
> > Same thing for the "c<motion>" command and such.
> > Good to know that there is already the macro for undo undo grouping !
> >
> >
> >
> >
> > > >
> > > <SNIP>
> > > > Tell me what do you think :)
> > > >
> > > I like it.  I think that right now I would like it most if you thought
> > > about issues like the "r" command, if we can get a framework that
> > > covers all those cases it will be really good in the long run.
> > I'll take a look to define pattern and think about a way to include
> > all forms of vim commands, maybe those like d3d too :)
> > I just hope it wont be too hard for a noob like me ^^
> >
> > >Even
> > > though I just posted saying "let's not move to Flexichain right now",
> > > I'm leaning that way again.  I'll write up my thoughts to the list,
> > > but it basically boils down to the fact that being able to treat the
> > > buffer as a giant string has many advantages over the list of lines
> > > approach.
> > > The problem with changing out buffers right now is that we make lots
> > > of assumptions about the list of lines structure.  We basically need
> > > to change:
> > > buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> > > regions, view, ncurses-io, undo
> > > But, each module will benefit greatly from being able to treate the
> > > buffer as a big string.
> > > Guess I have a lot of work ahead :)
> > >
> > > Cheers
> > > Brad
> > >
> > I thought you wanted to use a buffer made of a list of flexichains
> > (gap buffers), not just one gap buffer to handle our buffer..
> > reading the flexichains docs it seems that it's better to use a list
> > or a sequence of gap buffers rather than a big gap buffer.. In terms
> > of performance it seems. I don't know wich are the great benefits that
> > you are talking about though, so it could be that it's better having a
> > little less performance and a clerarer code, at least now :)
> >
> > I think that we should put an abstraction layer also there, between
> > the buffer module and all those modules that now depend on the
> > implementation (the ones you listed above) ,if it makes sence, maybe
> > one day we'll want to change the buffer implementation again, and it
> > would be good not to change those modules again.
> >
> > Tell me what you think, and if it is feasible to put an abstraction
> > layer also there :)
> >
> > I forgot to say, I find the idea of using the emacs api a really good
> > one! Going to have a look at it soon.
> > __
>
> Continuing with the "steal it" motif, I am thinking about stealing
> even more from Climacs.  The plan as it stands is to try and use
> Climacs files wholesale, including the buffer protocol, the undo
> protocol, etc.
> I don't fully know how to do it yet, but at least for a while you will
> probably need a Climacs code tree hanging around.
> http://www.cliki.net/Climacs
> dept-info.labri.fr/~strandh/climacs-internals.pdf
> dept-info.labri.fr/~strandh/climacs-user.pdf
>
> Basically the only parts of Vial that we can keep are the key
> handling.  This is probably almost a total rewrite.
> Sorry to have announced Vial and then immediately take a different
> tack.  If truth be told, I should have done this before I publicly
> announced - but it took going public for a third party to hit me with
> a cluestick.
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>

Mh, It sounds like a viper like project for climacs, is this the case?
I'll try climacs a little if it's the case, just to see how it performs.


From brad.beveridge at gmail.com  Wed Oct 25 14:23:06 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Wed, 25 Oct 2006 07:23:06 -0700
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <d0e2f05e0610250236p11b480f9m7ea545f0601c1b05@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240233q1efec587xfbcdd31b4dd79fca@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
	<de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>
	<d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
	<d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>
	<de95dc6f0610242251p3541c0d8maf6f584929eafda0@mail.gmail.com>
	<d0e2f05e0610250236p11b480f9m7ea545f0601c1b05@mail.gmail.com>
Message-ID: <de95dc6f0610250723p3616fce8gdc577befda250984@mail.gmail.com>

On 25/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > ---------- Forwarded message ----------
> > > From: Alessandro Piras <laynor at gmail.com>
> > > Date: Oct 24, 2006 5:41 PM
> > > Subject: Re: What will break with flexichain
> > > To: Brad Beveridge <brad.beveridge at gmail.com>
> > >
> > >
> > > On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > > ....
> > > > There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> > > > of undos.  The saving of the cursor shouldn't be required - if you
> > > > think about it, when you undo/redo you are playing back or unplaying
> > > > keystrokes.  If you are undoing an insert of "hello there", you should
> > > > delete 11 chars, and the point should be back before you inserted any
> > > > text.
> > >
> > > It works in most cases but in some don't...
> > > try theese things:
> > > insert "abcdefgh"
> > > move to the "d" letter
> > > delete "d" and "e" using the "x" command
> > > now undo the changes, you'll see the cursor going to the end of the
> > > line. instead of where it was before applying the x command.
> > >
> > > The same behavior presents when you insert text between words, let's
> > > say you have this line
> > >
> > > pino pigna
> > >
> > > you move the cursor between the 2 words, insert
> > > " is", go to normal mode and press u to undo. The cursor will go at
> > > the end of the line.
> > >
> > > Same thing for the "c<motion>" command and such.
> > > Good to know that there is already the macro for undo undo grouping !
> > >
> > >
> > >
> > >
> > > > >
> > > > <SNIP>
> > > > > Tell me what do you think :)
> > > > >
> > > > I like it.  I think that right now I would like it most if you thought
> > > > about issues like the "r" command, if we can get a framework that
> > > > covers all those cases it will be really good in the long run.
> > > I'll take a look to define pattern and think about a way to include
> > > all forms of vim commands, maybe those like d3d too :)
> > > I just hope it wont be too hard for a noob like me ^^
> > >
> > > >Even
> > > > though I just posted saying "let's not move to Flexichain right now",
> > > > I'm leaning that way again.  I'll write up my thoughts to the list,
> > > > but it basically boils down to the fact that being able to treat the
> > > > buffer as a giant string has many advantages over the list of lines
> > > > approach.
> > > > The problem with changing out buffers right now is that we make lots
> > > > of assumptions about the list of lines structure.  We basically need
> > > > to change:
> > > > buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> > > > regions, view, ncurses-io, undo
> > > > But, each module will benefit greatly from being able to treate the
> > > > buffer as a big string.
> > > > Guess I have a lot of work ahead :)
> > > >
> > > > Cheers
> > > > Brad
> > > >
> > > I thought you wanted to use a buffer made of a list of flexichains
> > > (gap buffers), not just one gap buffer to handle our buffer..
> > > reading the flexichains docs it seems that it's better to use a list
> > > or a sequence of gap buffers rather than a big gap buffer.. In terms
> > > of performance it seems. I don't know wich are the great benefits that
> > > you are talking about though, so it could be that it's better having a
> > > little less performance and a clerarer code, at least now :)
> > >
> > > I think that we should put an abstraction layer also there, between
> > > the buffer module and all those modules that now depend on the
> > > implementation (the ones you listed above) ,if it makes sence, maybe
> > > one day we'll want to change the buffer implementation again, and it
> > > would be good not to change those modules again.
> > >
> > > Tell me what you think, and if it is feasible to put an abstraction
> > > layer also there :)
> > >
> > > I forgot to say, I find the idea of using the emacs api a really good
> > > one! Going to have a look at it soon.
> > > __
> >
> > Continuing with the "steal it" motif, I am thinking about stealing
> > even more from Climacs.  The plan as it stands is to try and use
> > Climacs files wholesale, including the buffer protocol, the undo
> > protocol, etc.
> > I don't fully know how to do it yet, but at least for a while you will
> > probably need a Climacs code tree hanging around.
> > http://www.cliki.net/Climacs
> > dept-info.labri.fr/~strandh/climacs-internals.pdf
> > dept-info.labri.fr/~strandh/climacs-user.pdf
> >
> > Basically the only parts of Vial that we can keep are the key
> > handling.  This is probably almost a total rewrite.
> > Sorry to have announced Vial and then immediately take a different
> > tack.  If truth be told, I should have done this before I publicly
> > announced - but it took going public for a third party to hit me with
> > a cluestick.
> >
> > Cheers
> > Brad
> > _______________________________________________
> > vial-devel mailing list
> > vial-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> >
>
> Mh, It sounds like a viper like project for climacs, is this the case?
> I'll try climacs a little if it's the case, just to see how it performs.

Logically, a Viper mode for Climacs would be the best solution to the
goal of "a Vi like editor in CL, for CL".  I still suffer from "not
invented here" as much as the next guy, so we will see how I go.
If I do a Viper mode (I think I'll still call it Vial mode), the goals would be:
1) Proper Vi feel - not the bastard child Viper feel
2) Slime integration (would have needed to be done anyway)
3) Build a McClim backend on top of ncurses.

Cheers
Brad


From laynor at gmail.com  Wed Oct 25 17:40:53 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Wed, 25 Oct 2006 19:40:53 +0200
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <de95dc6f0610250723p3616fce8gdc577befda250984@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240233q1efec587xfbcdd31b4dd79fca@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
	<de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>
	<d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
	<d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>
	<de95dc6f0610242251p3541c0d8maf6f584929eafda0@mail.gmail.com>
	<d0e2f05e0610250236p11b480f9m7ea545f0601c1b05@mail.gmail.com>
	<de95dc6f0610250723p3616fce8gdc577befda250984@mail.gmail.com>
Message-ID: <d0e2f05e0610251040i14dcff10i6e3e10fc47844a2@mail.gmail.com>

On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 25/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > > ---------- Forwarded message ----------
> > > > From: Alessandro Piras <laynor at gmail.com>
> > > > Date: Oct 24, 2006 5:41 PM
> > > > Subject: Re: What will break with flexichain
> > > > To: Brad Beveridge <brad.beveridge at gmail.com>
> > > >
> > > >
> > > > On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > > > ....
> > > > > There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> > > > > of undos.  The saving of the cursor shouldn't be required - if you
> > > > > think about it, when you undo/redo you are playing back or unplaying
> > > > > keystrokes.  If you are undoing an insert of "hello there", you should
> > > > > delete 11 chars, and the point should be back before you inserted any
> > > > > text.
> > > >
> > > > It works in most cases but in some don't...
> > > > try theese things:
> > > > insert "abcdefgh"
> > > > move to the "d" letter
> > > > delete "d" and "e" using the "x" command
> > > > now undo the changes, you'll see the cursor going to the end of the
> > > > line. instead of where it was before applying the x command.
> > > >
> > > > The same behavior presents when you insert text between words, let's
> > > > say you have this line
> > > >
> > > > pino pigna
> > > >
> > > > you move the cursor between the 2 words, insert
> > > > " is", go to normal mode and press u to undo. The cursor will go at
> > > > the end of the line.
> > > >
> > > > Same thing for the "c<motion>" command and such.
> > > > Good to know that there is already the macro for undo undo grouping !
> > > >
> > > >
> > > >
> > > >
> > > > > >
> > > > > <SNIP>
> > > > > > Tell me what do you think :)
> > > > > >
> > > > > I like it.  I think that right now I would like it most if you thought
> > > > > about issues like the "r" command, if we can get a framework that
> > > > > covers all those cases it will be really good in the long run.
> > > > I'll take a look to define pattern and think about a way to include
> > > > all forms of vim commands, maybe those like d3d too :)
> > > > I just hope it wont be too hard for a noob like me ^^
> > > >
> > > > >Even
> > > > > though I just posted saying "let's not move to Flexichain right now",
> > > > > I'm leaning that way again.  I'll write up my thoughts to the list,
> > > > > but it basically boils down to the fact that being able to treat the
> > > > > buffer as a giant string has many advantages over the list of lines
> > > > > approach.
> > > > > The problem with changing out buffers right now is that we make lots
> > > > > of assumptions about the list of lines structure.  We basically need
> > > > > to change:
> > > > > buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> > > > > regions, view, ncurses-io, undo
> > > > > But, each module will benefit greatly from being able to treate the
> > > > > buffer as a big string.
> > > > > Guess I have a lot of work ahead :)
> > > > >
> > > > > Cheers
> > > > > Brad
> > > > >
> > > > I thought you wanted to use a buffer made of a list of flexichains
> > > > (gap buffers), not just one gap buffer to handle our buffer..
> > > > reading the flexichains docs it seems that it's better to use a list
> > > > or a sequence of gap buffers rather than a big gap buffer.. In terms
> > > > of performance it seems. I don't know wich are the great benefits that
> > > > you are talking about though, so it could be that it's better having a
> > > > little less performance and a clerarer code, at least now :)
> > > >
> > > > I think that we should put an abstraction layer also there, between
> > > > the buffer module and all those modules that now depend on the
> > > > implementation (the ones you listed above) ,if it makes sence, maybe
> > > > one day we'll want to change the buffer implementation again, and it
> > > > would be good not to change those modules again.
> > > >
> > > > Tell me what you think, and if it is feasible to put an abstraction
> > > > layer also there :)
> > > >
> > > > I forgot to say, I find the idea of using the emacs api a really good
> > > > one! Going to have a look at it soon.
> > > > __
> > >
> > > Continuing with the "steal it" motif, I am thinking about stealing
> > > even more from Climacs.  The plan as it stands is to try and use
> > > Climacs files wholesale, including the buffer protocol, the undo
> > > protocol, etc.
> > > I don't fully know how to do it yet, but at least for a while you will
> > > probably need a Climacs code tree hanging around.
> > > http://www.cliki.net/Climacs
> > > dept-info.labri.fr/~strandh/climacs-internals.pdf
> > > dept-info.labri.fr/~strandh/climacs-user.pdf
> > >
> > > Basically the only parts of Vial that we can keep are the key
> > > handling.  This is probably almost a total rewrite.
> > > Sorry to have announced Vial and then immediately take a different
> > > tack.  If truth be told, I should have done this before I publicly
> > > announced - but it took going public for a third party to hit me with
> > > a cluestick.
> > >
> > > Cheers
> > > Brad
> > > _______________________________________________
> > > vial-devel mailing list
> > > vial-devel at common-lisp.net
> > > http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> > >
> >
> > Mh, It sounds like a viper like project for climacs, is this the case?
> > I'll try climacs a little if it's the case, just to see how it performs.
>
> Logically, a Viper mode for Climacs would be the best solution to the
> goal of "a Vi like editor in CL, for CL".  I still suffer from "not
> invented here" as much as the next guy, so we will see how I go.
> If I do a Viper mode (I think I'll still call it Vial mode), the goals would be:
> 1) Proper Vi feel - not the bastard child Viper feel
> 2) Slime integration (would have needed to be done anyway)
> 3) Build a McClim backend on top of ncurses.
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> .
Ok :) just let me know what you decide to do, I'll take a look to
climacs if possible. Though yesterday I found climacs slow as hell,
but maybe It was something wrong with my system.


From brad.beveridge at gmail.com  Wed Oct 25 18:00:17 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Wed, 25 Oct 2006 11:00:17 -0700
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <d0e2f05e0610251040i14dcff10i6e3e10fc47844a2@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240233q1efec587xfbcdd31b4dd79fca@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
	<de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>
	<d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
	<d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>
	<de95dc6f0610242251p3541c0d8maf6f584929eafda0@mail.gmail.com>
	<d0e2f05e0610250236p11b480f9m7ea545f0601c1b05@mail.gmail.com>
	<de95dc6f0610250723p3616fce8gdc577befda250984@mail.gmail.com>
	<d0e2f05e0610251040i14dcff10i6e3e10fc47844a2@mail.gmail.com>
Message-ID: <de95dc6f0610251100g3855ebfdh3b63d26eed42cc6c@mail.gmail.com>

On 25/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > On 25/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > > On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > > > ---------- Forwarded message ----------
> > > > > From: Alessandro Piras <laynor at gmail.com>
> > > > > Date: Oct 24, 2006 5:41 PM
> > > > > Subject: Re: What will break with flexichain
> > > > > To: Brad Beveridge <brad.beveridge at gmail.com>
> > > > >
> > > > >
> > > > > On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > > > > ....
> > > > > > There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> > > > > > of undos.  The saving of the cursor shouldn't be required - if you
> > > > > > think about it, when you undo/redo you are playing back or unplaying
> > > > > > keystrokes.  If you are undoing an insert of "hello there", you should
> > > > > > delete 11 chars, and the point should be back before you inserted any
> > > > > > text.
> > > > >
> > > > > It works in most cases but in some don't...
> > > > > try theese things:
> > > > > insert "abcdefgh"
> > > > > move to the "d" letter
> > > > > delete "d" and "e" using the "x" command
> > > > > now undo the changes, you'll see the cursor going to the end of the
> > > > > line. instead of where it was before applying the x command.
> > > > >
> > > > > The same behavior presents when you insert text between words, let's
> > > > > say you have this line
> > > > >
> > > > > pino pigna
> > > > >
> > > > > you move the cursor between the 2 words, insert
> > > > > " is", go to normal mode and press u to undo. The cursor will go at
> > > > > the end of the line.
> > > > >
> > > > > Same thing for the "c<motion>" command and such.
> > > > > Good to know that there is already the macro for undo undo grouping !
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > >
> > > > > > <SNIP>
> > > > > > > Tell me what do you think :)
> > > > > > >
> > > > > > I like it.  I think that right now I would like it most if you thought
> > > > > > about issues like the "r" command, if we can get a framework that
> > > > > > covers all those cases it will be really good in the long run.
> > > > > I'll take a look to define pattern and think about a way to include
> > > > > all forms of vim commands, maybe those like d3d too :)
> > > > > I just hope it wont be too hard for a noob like me ^^
> > > > >
> > > > > >Even
> > > > > > though I just posted saying "let's not move to Flexichain right now",
> > > > > > I'm leaning that way again.  I'll write up my thoughts to the list,
> > > > > > but it basically boils down to the fact that being able to treat the
> > > > > > buffer as a giant string has many advantages over the list of lines
> > > > > > approach.
> > > > > > The problem with changing out buffers right now is that we make lots
> > > > > > of assumptions about the list of lines structure.  We basically need
> > > > > > to change:
> > > > > > buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> > > > > > regions, view, ncurses-io, undo
> > > > > > But, each module will benefit greatly from being able to treate the
> > > > > > buffer as a big string.
> > > > > > Guess I have a lot of work ahead :)
> > > > > >
> > > > > > Cheers
> > > > > > Brad
> > > > > >
> > > > > I thought you wanted to use a buffer made of a list of flexichains
> > > > > (gap buffers), not just one gap buffer to handle our buffer..
> > > > > reading the flexichains docs it seems that it's better to use a list
> > > > > or a sequence of gap buffers rather than a big gap buffer.. In terms
> > > > > of performance it seems. I don't know wich are the great benefits that
> > > > > you are talking about though, so it could be that it's better having a
> > > > > little less performance and a clerarer code, at least now :)
> > > > >
> > > > > I think that we should put an abstraction layer also there, between
> > > > > the buffer module and all those modules that now depend on the
> > > > > implementation (the ones you listed above) ,if it makes sence, maybe
> > > > > one day we'll want to change the buffer implementation again, and it
> > > > > would be good not to change those modules again.
> > > > >
> > > > > Tell me what you think, and if it is feasible to put an abstraction
> > > > > layer also there :)
> > > > >
> > > > > I forgot to say, I find the idea of using the emacs api a really good
> > > > > one! Going to have a look at it soon.
> > > > > __
> > > >
> > > > Continuing with the "steal it" motif, I am thinking about stealing
> > > > even more from Climacs.  The plan as it stands is to try and use
> > > > Climacs files wholesale, including the buffer protocol, the undo
> > > > protocol, etc.
> > > > I don't fully know how to do it yet, but at least for a while you will
> > > > probably need a Climacs code tree hanging around.
> > > > http://www.cliki.net/Climacs
> > > > dept-info.labri.fr/~strandh/climacs-internals.pdf
> > > > dept-info.labri.fr/~strandh/climacs-user.pdf
> > > >
> > > > Basically the only parts of Vial that we can keep are the key
> > > > handling.  This is probably almost a total rewrite.
> > > > Sorry to have announced Vial and then immediately take a different
> > > > tack.  If truth be told, I should have done this before I publicly
> > > > announced - but it took going public for a third party to hit me with
> > > > a cluestick.
> > > >
> > > > Cheers
> > > > Brad
> > > > _______________________________________________
> > > > vial-devel mailing list
> > > > vial-devel at common-lisp.net
> > > > http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> > > >
> > >
> > > Mh, It sounds like a viper like project for climacs, is this the case?
> > > I'll try climacs a little if it's the case, just to see how it performs.
> >
> > Logically, a Viper mode for Climacs would be the best solution to the
> > goal of "a Vi like editor in CL, for CL".  I still suffer from "not
> > invented here" as much as the next guy, so we will see how I go.
> > If I do a Viper mode (I think I'll still call it Vial mode), the goals would be:
> > 1) Proper Vi feel - not the bastard child Viper feel
> > 2) Slime integration (would have needed to be done anyway)
> > 3) Build a McClim backend on top of ncurses.
> >
> > Cheers
> > Brad
> > _______________________________________________
> > vial-devel mailing list
> > vial-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> > .
> Ok :) just let me know what you decide to do, I'll take a look to
> climacs if possible. Though yesterday I found climacs slow as hell,
> but maybe It was something wrong with my system.

I'm going to try to get vanilla Climacs going tonight to see how fast
it is.  What speed system do you have?  Beach on IRC mentioned two
reasons for Climacs slowness - excessive parsing of the Lisp code and
possibly the McClim layer.  Right now I'm not too concerned with
speed, as long as it is usable - ie, keypresses don't feel like they
take time to appear.
I've posted to Climacs devel asking for hints on how to do the Vi
style mappings.

Logically, adding a Vi mode to Climacs is the answer, but in reality I
don't know yet.

Cheers
Brad


From laynor at gmail.com  Wed Oct 25 23:31:05 2006
From: laynor at gmail.com (Alessandro Piras)
Date: Thu, 26 Oct 2006 01:31:05 +0200
Subject: [vial-devel] Re: What will break with flexichain
In-Reply-To: <de95dc6f0610251100g3855ebfdh3b63d26eed42cc6c@mail.gmail.com>
References: <de95dc6f0610231958r139ea477pbaf9ea0e1550e358@mail.gmail.com>
	<d0e2f05e0610240419q5e4fd383rd92c6f87cf3f5b9b@mail.gmail.com>
	<de95dc6f0610240749i14a03972gd10a9ea630064a4d@mail.gmail.com>
	<d0e2f05e0610240841q2d2f2cf6t96fa79f45cfde310@mail.gmail.com>
	<d0e2f05e0610240856q373d3096w98ee2286567d1778@mail.gmail.com>
	<de95dc6f0610242251p3541c0d8maf6f584929eafda0@mail.gmail.com>
	<d0e2f05e0610250236p11b480f9m7ea545f0601c1b05@mail.gmail.com>
	<de95dc6f0610250723p3616fce8gdc577befda250984@mail.gmail.com>
	<d0e2f05e0610251040i14dcff10i6e3e10fc47844a2@mail.gmail.com>
	<de95dc6f0610251100g3855ebfdh3b63d26eed42cc6c@mail.gmail.com>
Message-ID: <d0e2f05e0610251631p4aa50e28nd460ae49c34d56c@mail.gmail.com>

On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> On 25/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > On 25/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > > On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > > > On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> > > > > > ---------- Forwarded message ----------
> > > > > > From: Alessandro Piras <laynor at gmail.com>
> > > > > > Date: Oct 24, 2006 5:41 PM
> > > > > > Subject: Re: What will break with flexichain
> > > > > > To: Brad Beveridge <brad.beveridge at gmail.com>
> > > > > >
> > > > > >
> > > > > > On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > > > > > ....
> > > > > > > There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> > > > > > > of undos.  The saving of the cursor shouldn't be required - if you
> > > > > > > think about it, when you undo/redo you are playing back or unplaying
> > > > > > > keystrokes.  If you are undoing an insert of "hello there", you should
> > > > > > > delete 11 chars, and the point should be back before you inserted any
> > > > > > > text.
> > > > > >
> > > > > > It works in most cases but in some don't...
> > > > > > try theese things:
> > > > > > insert "abcdefgh"
> > > > > > move to the "d" letter
> > > > > > delete "d" and "e" using the "x" command
> > > > > > now undo the changes, you'll see the cursor going to the end of the
> > > > > > line. instead of where it was before applying the x command.
> > > > > >
> > > > > > The same behavior presents when you insert text between words, let's
> > > > > > say you have this line
> > > > > >
> > > > > > pino pigna
> > > > > >
> > > > > > you move the cursor between the 2 words, insert
> > > > > > " is", go to normal mode and press u to undo. The cursor will go at
> > > > > > the end of the line.
> > > > > >
> > > > > > Same thing for the "c<motion>" command and such.
> > > > > > Good to know that there is already the macro for undo undo grouping !
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > >
> > > > > > > <SNIP>
> > > > > > > > Tell me what do you think :)
> > > > > > > >
> > > > > > > I like it.  I think that right now I would like it most if you thought
> > > > > > > about issues like the "r" command, if we can get a framework that
> > > > > > > covers all those cases it will be really good in the long run.
> > > > > > I'll take a look to define pattern and think about a way to include
> > > > > > all forms of vim commands, maybe those like d3d too :)
> > > > > > I just hope it wont be too hard for a noob like me ^^
> > > > > >
> > > > > > >Even
> > > > > > > though I just posted saying "let's not move to Flexichain right now",
> > > > > > > I'm leaning that way again.  I'll write up my thoughts to the list,
> > > > > > > but it basically boils down to the fact that being able to treat the
> > > > > > > buffer as a giant string has many advantages over the list of lines
> > > > > > > approach.
> > > > > > > The problem with changing out buffers right now is that we make lots
> > > > > > > of assumptions about the list of lines structure.  We basically need
> > > > > > > to change:
> > > > > > > buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> > > > > > > regions, view, ncurses-io, undo
> > > > > > > But, each module will benefit greatly from being able to treate the
> > > > > > > buffer as a big string.
> > > > > > > Guess I have a lot of work ahead :)
> > > > > > >
> > > > > > > Cheers
> > > > > > > Brad
> > > > > > >
> > > > > > I thought you wanted to use a buffer made of a list of flexichains
> > > > > > (gap buffers), not just one gap buffer to handle our buffer..
> > > > > > reading the flexichains docs it seems that it's better to use a list
> > > > > > or a sequence of gap buffers rather than a big gap buffer.. In terms
> > > > > > of performance it seems. I don't know wich are the great benefits that
> > > > > > you are talking about though, so it could be that it's better having a
> > > > > > little less performance and a clerarer code, at least now :)
> > > > > >
> > > > > > I think that we should put an abstraction layer also there, between
> > > > > > the buffer module and all those modules that now depend on the
> > > > > > implementation (the ones you listed above) ,if it makes sence, maybe
> > > > > > one day we'll want to change the buffer implementation again, and it
> > > > > > would be good not to change those modules again.
> > > > > >
> > > > > > Tell me what you think, and if it is feasible to put an abstraction
> > > > > > layer also there :)
> > > > > >
> > > > > > I forgot to say, I find the idea of using the emacs api a really good
> > > > > > one! Going to have a look at it soon.
> > > > > > __
> > > > >
> > > > > Continuing with the "steal it" motif, I am thinking about stealing
> > > > > even more from Climacs.  The plan as it stands is to try and use
> > > > > Climacs files wholesale, including the buffer protocol, the undo
> > > > > protocol, etc.
> > > > > I don't fully know how to do it yet, but at least for a while you will
> > > > > probably need a Climacs code tree hanging around.
> > > > > http://www.cliki.net/Climacs
> > > > > dept-info.labri.fr/~strandh/climacs-internals.pdf
> > > > > dept-info.labri.fr/~strandh/climacs-user.pdf
> > > > >
> > > > > Basically the only parts of Vial that we can keep are the key
> > > > > handling.  This is probably almost a total rewrite.
> > > > > Sorry to have announced Vial and then immediately take a different
> > > > > tack.  If truth be told, I should have done this before I publicly
> > > > > announced - but it took going public for a third party to hit me with
> > > > > a cluestick.
> > > > >
> > > > > Cheers
> > > > > Brad
> > > > > _______________________________________________
> > > > > vial-devel mailing list
> > > > > vial-devel at common-lisp.net
> > > > > http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> > > > >
> > > >
> > > > Mh, It sounds like a viper like project for climacs, is this the case?
> > > > I'll try climacs a little if it's the case, just to see how it performs.
> > >
> > > Logically, a Viper mode for Climacs would be the best solution to the
> > > goal of "a Vi like editor in CL, for CL".  I still suffer from "not
> > > invented here" as much as the next guy, so we will see how I go.
> > > If I do a Viper mode (I think I'll still call it Vial mode), the goals would be:
> > > 1) Proper Vi feel - not the bastard child Viper feel
> > > 2) Slime integration (would have needed to be done anyway)
> > > 3) Build a McClim backend on top of ncurses.
> > >
> > > Cheers
> > > Brad
> > > _______________________________________________
> > > vial-devel mailing list
> > > vial-devel at common-lisp.net
> > > http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> > > .
> > Ok :) just let me know what you decide to do, I'll take a look to
> > climacs if possible. Though yesterday I found climacs slow as hell,
> > but maybe It was something wrong with my system.
>
> I'm going to try to get vanilla Climacs going tonight to see how fast
> it is.  What speed system do you have?  Beach on IRC mentioned two
> reasons for Climacs slowness - excessive parsing of the Lisp code and
> possibly the McClim layer.  Right now I'm not too concerned with
> speed, as long as it is usable - ie, keypresses don't feel like they
> take time to appear.
> I've posted to Climacs devel asking for hints on how to do the Vi
> style mappings.
>
> Logically, adding a Vi mode to Climacs is the answer, but in reality I
> don't know yet.
>
> Cheers
> Brad
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>
I have an Intel centrino based machine, can't remember the MHz, I
remember it's number, it's M725 if i remember right. It's a 1 year old
laptop, with 512 MB Ram, fresh ubuntu dapper installation. The
slowness wasn't so much on text inserting, it was on cursor moving,
especially when hitting parentesis (parens matching). also it
highlights parens displaying them in bold (it's surely customizable i
guess though). When hitting parens, it seems it has to redisplay yhe
whole buffer, it seems also that the lines "move" on the display when
matching parens, making the line with the matched parens broader... I
don't know why and hope it's something that has to do with my setup (I
installed it via asdf-install though, so it should be a normal
setup...), but I think that an editor should run on a 700 Mhz pc
without any problem (emacs and vim do). Anyway, I noticed another
strange thing, when I load files it gives some errors before loading,
so maybe that slowness is something that has to do with those errors.
Let me know about your experience with climacs, maybe it's just
something wrong with my system.

Ps. gnu emacs runs superfast on my pc.


From brad.beveridge at gmail.com  Mon Oct 30 03:21:47 2006
From: brad.beveridge at gmail.com (Brad Beveridge)
Date: Sun, 29 Oct 2006 19:21:47 -0800
Subject: [vial-devel] Experiments in the land of Climacs
Message-ID: <de95dc6f0610291921j67e8dd6oce1bb3025471b4b8@mail.gmail.com>

I  mentioned in an earlier email that I felt I needed to at least
investigate the possibility of using Climacs as the substrate for
Vial.
This weekend I have seriously investigated it.  Basically, something
of the order of 90% of things that Vial wants to do, Climacs also
wants to do.  So the good news is that there is a lot of potential for
reuse, things like buffer management, syntax highlighting, basic
editing commands, etc.  The bad news is that Climacs is big and will
take time to figure out, and converting it to use Vi style key
handling is a big issue.  Also, lots of Climacs assumes that it is in
a Clim environment.  This adds up to a huge task to take some of
Climacs and no Clim and make something work.
I prefer to develop incrementally, with small improvements.  With that
in mind here is my rough proposal for Vial's development.

1) Continue work on the current version of Vial until it has support
for Slime, which is my original and main goal.  This Vial will have
the following features/bugs:
 - not aiming for exact Vim replication.
 - core editing features only, fancy features (macros, visual mode,
correct syntax highlighting) are not implemented unless really
required
 - code is allowed to be somewhat ugly as this version is almost a
complete throw away
 - minor bugs will be tolerated as long as they are well known
 - The major feature that must be well coded is the Slime support, it
is potentially the only part that will be kept.
 - At this stage we have a good debugger, and an acceptable editor.

2) There is ongoing Climacs work to make the key handling more
general, so general that it will support Vi style modes.  Hopefully by
the time #1 is ready, this support will be part of Climacs.  At this
stage I will attempt to:
  - Integrate Vi style key handling and bindings into Climacs
  - Integrate Slime support into Climacs.
 - This will be Vial v2, I may stop here.

3) I'm largely a console guy, long term I would like to see a fancy
Vial running in a terminal.  This would be done by implementing an
Ncurses backend for McClim.

So, although I've spend much of the weekend trying to tease apart
Climacs, ultimately I think I will go with the "worse is better"
approach and continue with the code base I currently have.  The major
change in my thinking is that the current code base just became a
throw-away item, and what is acceptable for the editing features
dropped.  I think that Vial is currently almost an acceptable editor,
so I will now work on Slime support.

Cheers
Brad