It’s been a while since I first blogged about ni. I’ve been working on it from time to time and I made quite a bit of progress. I hope to put up a bazaar branch somewhere soon (I know - all the cool kids are using git).
What to name this thing?
I was just going to call it all “ni” which was supposed to be pythonic, a pun on “vi” and maybe it would just stand for “New and Improved”, but I now realise that since (in theory, hopefully) there will be multiple actual editors using the same framework, I should probably name the framework one thing and the editor I’m building with it something else in order to avoid confusion.
I’m not sure yet, but I think I’ll call the framework “moe” (for My Own Editor, a play on “joe” and also my favourite Simpsons character) and then I’ll just call my GTK based editor “ni”.
Urwid
At first I wrote a terminal editor based on my framework using urwid. It is more of a proof of concept and I suspect in future it will probably lag behind, because a lot of the things I want to play with just won’t work in a terminal environment (notably modern key bindings, the document list/tree widget mentioned below and JEdit-like search results)
At least the urwid-based editor helps when I have to come up with a common interface that will be used by all the editors, because the code is quite different from the GTK based one.
GTK
I’m currently working on a GTK editor (that uses the framework / implements the interfaces - not sure about the correct terminology yet). It is progressing quite nicely. I basically built my own text editing widget that uses a gtk Drawingarea and some scrollbar widgets in a table. Obviously this is a lot more work than just using a textview or sourceview widget, but necessary, because I want to reuse my core functionality across different actual editors and GUI frameworks. I plugged in the same pygments syntax highlighting code I use in the urwid-based one and average latency seems to be around 20ms. I think this is tolerable and quite impressive considering the entire editing “widget” is written in python code and I only made the most obvious optimisations (basically I try to only re-lex parts of the document. I back-trace to a safe-ish starting point and lex from there and only enough to fill the screen)
Why am I writing this again?
The big reason for writing my own text editor is because I want to experiment with working with multiple open files at the same time. None of the mayor text editors handle this very well in my opinion. Perhaps it is some kind of web development phenomenon, but I often catch myself with something like 50 files open at the same time (sometimes even more than that). I want to be able to find the open files (documents) and switch to them quickly. The best solution to this that I know of is JEdit’s BufferList plugin where open files go into some kind of a collapsed tree structure.
The other big reason is because most text editors suck at find/replace. Again.. JEdit’s got the best solution with its Hypersearch. A want a dialog and modern regular expressions and I want to be able to filter recursively through my open documents or file system and only inside files matching certain criteria. JEdit’s find/replace functionality is amazing, but I want more.
Also, I feel like there’s a need for an editor framework that’s cross platform, but allows you to easily build apps that use the native GUI toolkit. I think editors should be opinionated software, so you might even have multiple editors that use the same GUI toolkit and is aimed at the same platform, but have different user interfaces. I think programmers should easily be able to build their own text editor that works the way they want. Almost like Emacs, but more modern and obviously no elisp. I’d like to program such a thing in Python.
I guess I could try and extend JEdit, but the fact that it’s written in Java and uses Swing also bothers me. That and the fact that it is the only reason for my Java dependency. I realise it is a bit weird that I really love JEdit, use it every day, but still want to replace it ;)
I have a bunch of other little features that I want to experiment with, but I’ll write about them later.
Progress
The document tree widget thing is working, the text editing widget, navigating around, copy, paste, delete, undo, redo, etc is working, syntax highlighting is working. Also, most of the editor, view, document, action interface (some abstraction and also lots of indirection) is laid out, but it will obviously grow as I add more functionality in order to make this a real, useful text editor.
So what’s still needed for it to be useful? Mainly the open/save as/confirm/etc dialogs and I still have to get to JEdit-style find/replace (which is the big one).
After that I need some global settings and per-document settings. I might also introduce the idea of projects (really just a directory) and then per-project settings.
Leave a Response