vih 18
Over the past few days, I’ve been tinkering with a little project I’ve called vih – it’s a vi clone written in Haskell. Here’s the git repo.
The way I’ve started it is rather naive, and frankly I’m surprised I that I had gotten as far as I did without curses and with the simple data structure I choose. Rather than using a clever representation for a buffer, I decided to just use a String. What this means is that every time a character is inserted into a buffer, the whole thing is split and reconstituted. I’m not using Data.ByteString or Data.ByteString.Lazy either. I suppose that I’ll move toward a more sensible data structure in a while but right now typing is comfortable even with all of that work going on.
My intention in doing this was to start to get a sense of how data structures evolve in Haskell by growing something large from a small seed. The primary data structure that I’m using right now is called EditBuffer and I notice that quite a few of my functions translate an EditBuffer to another EditBuffer. This seems to work fine, however I find that I almost always have to label the buffer in the argument list and deconstruct it. I haven’t seen pervasive use of labels like that in Haskell code I’ve looked at, so I’m wondering if my mapping of functions to data structures is odd.
Right now, vih supports insert and command mode (toggled with ‘i’ and ‘ESC’), the h, j, k, l cursor movements, line deletion with ‘dd’, home with ‘gg’, end of file with ‘G’, `in line’ positioning with ‘0’ and ’$’, insert new line after with ‘o’, and delete current char with ‘x’. No file I/O yet.
Have a look, fork or contribute.
Where are the unit tests!?
I knew someone would ask that. ;-) I decided to go test-after with this and use QuickCheck. I’m just having a bit of trouble thinking about these editing operations in terms of properties.
resisting… urge… to discuss… the evils… of bad UI designs….
Some properties you can test for; if you type a character, the length of the buffer increases; if you type a character and the point is at the end of the buffer, the character at the beginning of the buffer doesn’t change; if you delete a line, the buffer shrinks, etc., etc.
Jonathan: Yes, I’m going down that road ( http://github.com/michaelfeathers/vih/blob/e5837eb66a9d565be4d2c2c10ef4d4b8fbe9ddcb/eb_checks.hs ) I’m used to seeing higher level properties, however. There are some odd asymmetries that I have to think about.
Have you seen Yi?
http://haskell.org/haskellwiki/Yi
Why not contribute to yi instead? http://haskell.org/haskellwiki/Yi
Yea, second the comment about Yi.
I applaud your efforts. It appears to me that this is a learning experience for you. So, I think you should continue and don’t worry about contributing to another, mature project. If you later decide you’ve learned enough, then go for that angle.
Michael, deconstructing structured data is quite common in functional languages that don’t have side-effects, precisely because that’s really the only way to gain access to the fields you need without resorting to state monads and/or transformers. So, don’t fret.
However, if you find that a number of fields go unused, and you find that you’re tiring of always deconstructing them, you might find refactoring the structures might be a good idea. E.g., convert:
data Foo = Foo Int Int Int Int Int
into:
data Rect = Rect Int Int Int Int data Foo = Foo Rect Int
That way, you cut the number of fields to deconstruct substantially.
And once again, Object Mentor’s blogging software munges formatting. You guys REALLY gotta fix this. :(
Added ‘word forward with ‘w’ and autoscrolling.
+1 to contributing to Yi
Nicholas: What I’d really like to do is refactoring tooling for Yi or Leksah, but I have to ramp up my skills. Met someone at a conference last year who has the same interest. Still need to see whether it would be good to work on.. what’s currently done.. whether the projects have anything under way, or are interested.. what the state of HaRe is, etc.
Micheal: These are all great plans. Note also that contributing to Yi can be done to improves your skills. There are a lot of simple additions/integrations you can make especially about re-factoring.
Hi Micheal,
Just a little non tech comment VIH is the french acronym for HIV… it’s just a lttle confusing for french people like me !
Great job anyway.
Seen the Yi editor? It’s got a vim mode and an emacs mode.
Very cool work though!
I think this project is worth doing, because Yi is GPL’d, and as far as I can tell, (reading license.txt) the Vih license is MIT. (I think) Without getting into license wars, I think that using a less restrictive license is a perfectly reasonable case for a separate project.
Besides that, I couldn’t get Yi to compile on my machine…
I might contribute to this project in the future.