- Core editor (internal representation, etc.)
- Key bindings (so you could easily create an emacs instead of a vi)
- Rendering
- Scripting language (for customized behavior)
Finally, make sure you thoroughly document these building blocks, so others can create really cool stuff with it. Also, think of possible use-cases when defining the modules. A smart architecture could allow for a collaborative editor, for example.
The key bindings are also separate. Getting emacs bindings is not much more than changing this line [0]. Only adding the bindings for the window management and emacs command line is still to be done. (I know that emacs is actually much more than only its key bindings, but you know what I mean.)
The rendering is also independent. There are two backends: vt100 terminals and the windows console. (Honesly, my main focus is vt100, but any render back-end is possible. I think even graphical)
The same for the event loops by the way, it can run on a couple of event loops. For instance asyncio.
Documentation will follow. prompt-toolkit has already quite a lot of examples, and there's a lot of documentation in the code itself. But I agree that we should keep improving.
Cheers!
[0] https://github.com/jonathanslenders/pyvim/blob/master/pyvim/...
There are plenty of examples in the repo that cover most of the features in the library. The awesome thing is all of the examples fit in a single page, a testament to the power and simplicity of the library.
I built pgcli (https://github.com/dbcli/pgcli) almost entirely by reading the examples.
"Python, huh? Seems like typos in uncommon branches of the code would cause it to randomly fail at runtime, losing your work!"
"Now evmar, don't be such a internet nay-sayer, plenty of people write reliable Python code. You just need tests and... yep, there's a tests directory right there in the repository."
"Let's take a look. ...there's only one test!?"
It looks pretty neat other than that, though.
In the process I have been writing unit tests. Previously the program didn't have any, which was really dumb. It was dumb because, in the three days I've spent doing this, I have found (and fixed) so, _so_ many bugs.
And now I have a decent set of tests, I can change something, rerun them, and have a pretty good idea of whether it worked or not. I don't even have to run the program!
Unit tests. They Will Save You Time™.
But to be clear, in my day job I work on an app with 350k lines of Python in it and the reason I know it mostly works is due to our test coverage. As someone else mentioned in this thread, a lack of tests should not give you confidence regardless of the language.
Maybe not - Python itself can provide some crash protection. Run it this way: python -i run_pyvim.py. Then if pyvim crashes, Python will still be running with all your work still there. Maybe you can just type run() at the Python prompt to resume the session in almost the state you left it -- depending on how run() is coded, how much re-initialization it does.
Q: Why Python?
A: The only alternative would be Haskell, but I still have to learn that.
However I managed to build a _very_ basic proof-of-concept editor (no dependencies) in just a few hundreds lines of code which I could explain, but until now I was too shy to share it as it did not involve magic abstract Haskell-foo ... ;)
Please don't be, simple understandable Haskell code is very nice :)
Plus if there is a better way of doing it you get to find that out too.
"Gets the job done in just a few hundred lines of easily-explained code" is a terrific standard to meet.
"Magic abstract Haskell-fu" cannot improve such a program very much.
It's an automatic translation of the C version.
Like tomp said 4 hours ago: Like vim, just slower.™
Why did I create Pyvim?
There are several reasons.
The main reason is maybe because it was a small step after I created the Python prompt-toolkit library. That is a library which is actually only a simply pure Python readline replacement, but with some nice additions like syntax highlighting and multiline editing. It was never intended to be a toolkit for full-screen terminal applications, but at some point I realised that everything we need for an editor was in there and I liked to challenge its design. So, I started an editor and the first proof of concept was literally just a few hundred lines of code, but it was already a working editor.
The creation of pyvim will make sure that we have a solid architecture for prompt-toolkit, but it also aims to demonstrate the flexibility of the library. When it makes sense, features of pyvim will move back to prompt-toolkit, which in turn also results in a better Python REPL. (see ptpython, an alternative REPL.)
Above all, it is really fun to create an editor.
Every clone I see try to reproduce vim usage, but none really try to run vimfiles. I think running vimfiles is a must have for a clone to get real users.
Does it work with unicode Indic characters?