GSoC 2012: Vi Input Mode

Like last summer I am mentoring a student working on Kate’s Vi mode this summer. This year’s student is Vegard Øye from Oslo, Norway. I’ll let him introduce himself:

My name is Vegard Øye. I am a computer science student at the University of Oslo, Norway. I also have a bachelor’s degree in electrical engineering from Sør-Trøndelag University College in Trondheim, where I programmed for integrated circuits. It was a lot of fun, so I decided to embark on a grade with an even larger emphasis on programming.

My goal is to make modal editing more widespread outside of Vim. There is a Zen-like benefit to using a tool that does just what you tell it to – slicing and dicing text with surgical precision. My focus is not on adding new features to Kate (although I have implemented a few), but on sharpening existing functionality. In particular, I want to improve the integration between Kate’s vi mode and its extension system, as well as sort out various bugs pertaining to the vi mode.

Vegard has already done some really great work, and his changes should be trickling in to Kate’s git repository the next weeks. You can follow his work at http://quickgit.kde.org/index.php?p=clones%2Fkate%2Fvegardoye%2Fvegard_gsoc_2012.git.

Why KDE, and Kate

I’ve been using and contributing to KDE on-and-off for a while, but our friends over in Gnome land were already busy by the time I got into the game. So why did I conceptually commit to KDE, and thence Kate? Consistency.

I grew up on VAX/VMS where it was possible – and even easy – to mix Ada code with C and Pascal, mix in a CLI that used the standard parser, generate error messages that looked and *were* like every other message in the system. Everything felt integrated.

And the editors? Ah yes, the editors. VAX EDT was where I started, and I *loved* the fact that I used the same editor whether I was writing a VAXmail, posting a VAXnote, or editing a file. So it was a bit of a dilemma when I encountered VAX Emacs, with all its seductive extensibility. I ended up using Emacs for serious editing, and EDT for everything else…that was hateful. Eventually, TPU and its precocious offspring LSE restored the status ante, and my sanity.

Scroll forward a few years, past Windows NT 3.5 and Visual Studio where I got hooked on GUIs, and we get to Qt and KDE libs. Even though there were several KDE text editors in those early days, it was a reasonable bet we’d rationalise, and I’m delighted to say we did (even when Kmail’s default isn’t KWrite – at least the look’n'feel was the same). I even went round making every Find and Replace dialog throughout KDE the same.

So we get to Kate. Right out of the box, even in its Kate 3 incarnation, I loved Kate. Standalone was good, in KDevelop it was even better. I didn’t miss the relative lack of extensibility because well, it did pretty much everything I wanted. And then I changed job…

RFC: Exporting JavaScript API

Since quite some time, Kate Part has build-in scripting support through JavaScript. Our plan is to make this API public, so other applications like Kile, Kate App and KDevelop can use it. However, we are currently unsure how to best implement it, so this is a rfc to get feedback.

The bindings for a Kate Document are for instance located in part/script/katescriptdocument.h (header, implementation). As you can see, there are functions like

Q_INVOKABLE bool insertLine(int line, const QString &s),

which can be invoked in our scripting by a call of ‘document.insertLine(5, “hello world”)’. The API only contains basic functions. But for instance Kile maybe also wants to provide a function called ‘document.insertSection()’ or similar LaTeX related functions. The question now is as follows: How can Kile extend our QObject based prototype with their own QObject based classes?

We do not want to make the class KateScriptDocument public. Instead, we just want to return a QScriptValue containing a QObject based KateScriptDocument. You can think of the problem also as follows:

// in Kile:
QScriptEngine *engine = ...;
KTextEditor::Document *kteDocument = ...;

QObject* kateScriptDocument = kteDocument->scriptDocument();
engine->globalObject().setProperty("document", engine->newQObject(kateScriptDocument));
// at this point, the JavaScript object 'document' contains all KateScriptDocument functions

// next, we want to add the Kile related document functions
KileTextDocument* kileDocument = ...;
QObject* kileScriptDocument = kileDocument->...(); // some function that returns the binginds object

// now: how can we populate the 'document' property with the functions in kileScriptDocument?
engine->globalObject().setProperty("document", ? );

If you have any idea or other solutions how to do it right, please let us know!