In a project I’m currently working on I need to display the result of TeX code. So I thought it would be nice and accurate to compile the TeX code to produce a pdf, and then use libpoppler-qt4 to draw the pdf. This works in principal, but there is a licensing problem: libpoppler is GPL, and I want to use it in a LGPL library.

So I searched the net and found dvipng, which converts a dvi file to png. It even supports transparent backgrounds. So I could convert the dvi file to png through QProcess+dvipng, and then display the png file. This works, but whenever you scale the canvas the result looks ugly since png is not a vector graphic.

Next, I found pdf2svg that converts a pdf file into the scalable vector graphics format svg. In theory, I then can use QSvgRenderer to load and render the SVG on-the-fly using QSvgRenderer::render(QPainter*, …). So I first tested to convert the pdf to svg with this tool and then view it in InkScape. The result was perfect: InkScape renders the svg file exactly like Okular renders the pdf file:

So I looked into the source code of pdf2svg and saw that it uses libpoppler with Cairo. This reflects an additional dependency on cairo, so I went ahead and converted the cairo based code to Qt, using libpopper-qt4. The code basically boils down to:

// create poppler pdf document
Poppler::Document *document = Poppler::Document::load(args[1]);
document->setRenderBackend(Poppler::Document::ArthurBackend);
document->setRenderHint(Poppler::Document::Antialiasing, true);
document->setRenderHint(Poppler::Document::TextAntialiasing, true);
document->setRenderHint(Poppler::Document::TextHinting, true);
document->setRenderHint(Poppler::Document::TextSlightHinting, true);
document->setPaperColor(Qt::transparent);

// prepare QSvgGenerator as QPaintDevice
QSvgGenerator svgGenerator;
svgGenerator.setResolution(72); // resolution in dpi
svgGenerator.setFileName("out.svg");
svgGenerator.setSize(document->page(0)->pageSize());

// perform painting
QPainter painter(&svgGenerator);
document->page(0)->renderToPainter(&painter);
painter.end();

This code does indeed generate the svg code for the pdf file. However, the result is surprisingly ugly and wrong:

First, the pen seems too thick, and second the character ‘d’ is wrong on the left. I’ve tried changing the resolution (setResolution()) and also the page size (setSize()) of QSvgGenerator, always getting the same result. Searching the net reveals that QSvgGenerator seems to have quite some glitches with respect to WYSIWYG rendering. I tried to use QSvgGenerator before in 2009 and came out with unusable results. Maybe I’m missing something?

Update 1: It’s not QSvgGenerator that is to blame here. It’s indeed the Arthur backend of libpoppler. I send a patch to the poppler developers that fixes the issue with too bold glyphs. The pahts are still too inaccurate, though.

Update2: Using dvisvgm with the option –no-fonts results in an SVG file that QSvgRenderer renders correctly. So this is the current solution to get a TeX document rendered via SVG in Qt.

I have done some improvements in the plugins: python_console_ipython, python_autocomplete, python_utils, js_utils, xml_pretty and django_utils. These plugins I added a month and a half ago (except python_console_ipython) to the kate repository. I have done two improvements and a new feature:

• Now they work with Python2 and Python3 (except python_autocomplete, this only works with Python2, due pysmell dependence)
• Now they have a configuration page (except python_autocomplete, this should not have configuration parameters)

Page Config Plugins

The new feature is the integration of the python_autocomplete and python_console_ipython plugins with the project plugin. The behaviour of these plugins depends of the loaded project. That is to say, the python_autocomplete plugin autocompletes with our project modules. Currently the kate community is working to add a new python autocomplete  using jedi (this will work with Python2 and Python3).

Python Autocomplete (with our modules)

And the python_console_ipython plugin has something that we can name the project console. A ipython shell with the python path of our project and with the environments variables that the project plugin needs.

IPython Console (converted in a django shell)

To use this we need to add in the project file (.kateproject) a new attribute named “python”, with this structure:

 {
  "name": "MyProject",
  "files": [ { "git": 1 } ],
  "python": {
        "extraPath": ["/python/path/1",
                      "/python/path/2",
                      "/python/path/n"
        ],
        "environs": {"key": "value"},
        "version": "3.2"
    }
 }

I am a django developer, as we say in Django we can come to have a django shell (python manage.py shell) integrated in our editor. But this feature is a generic feature not tied to Django. This feature can be used by other Python developers. I have added only a specific feature to the django developers. If we set in the project file (.kateproject) the attribute projectType with the value Django, the ipython shell automatically loads the models and the settings like a shell_plus does.

  {
   "name": "MyProject",
   "files": [ { "hg": 1 } ],
   "python": {
        "extraPath": ["/python/path/1",
                      "/python/path/2",
                      "/python/path/n"
        ],
        "environs": {"DJANGO_SETTINGS_MODULE": "myproject.settings"},
        "version": "2.7.3",
        "projectType": "django"
    }
  }

I hope you like it

If someone is interested in doing some coding for Kate-Part, Kate, KTexteditor during this years  Summer of Code, just drop a proposal at the kwrite-devel mailing list for discussion.

I just started to clean up the content of kate.git, moving things around, fixing compile warnings and similar stuff.

I stumbled over warnings in our dbus interfaces.

The main use of them is to allow Kate to reuse an existing instance for opening files and sessions. This part (e.g. the interface of the application object itself) works fine and is needed.

But all other interfaces, like the ones for docmanager, mainwindows, … are mostly non-existant or not implemented. I now play with the idea of just removing the nearly empty skeleton implementations, as it seems nobody missed them during the complete 4.x series.

Is there somebody out there that actually uses them and if, how?

In KDE 4.10, the “Find All” and “Replace All” highlights all matches and at the same time shows a passive notification in a bar below the view. This bar is animated, and takes quite a lot of place in addition to the search & replace bar.

Since some days, Kate Part can also show passive notifications floating in the view. Hence, we’ve changed the passive notification to appear on the bottom right as a small info message, showing the number of matches. However, in order to make this passive notification as small as possible, we removed the “Close” button, since the notification is hidden after 3 seconds anyway. Further, we removed the “Keep Highlighting” button. If you want to keep the highlights, just do not close the search & replace bar. The following video demonstrates this behavior, first for KDE 4.10, then how it currently will be in KDE 4.11 (watch the video in 720p):

In the kate.git master branch the text folding is now new and shiny.

In addition to be faster and less memory hungry (no folding tree is around if you fold nothing, it is only created on-demand exactly for the folded regions), the new code is less complex and smaller (and hopefully better documented + unit tested, it actually has a test for most internal operations).

There is actually now a clean separation, the folding does not mix with highlighting and can be used without it, too.

This allows for a better integration of indentation based foldings like in Python (and already fixes the most ugly miss-placements of folding regions there) and empowers the user to fold arbitrary regions manually.

This can be done at the moment with two kate commands (for the F7 command line):

• “fold” will create persistent fold for the current selection, this fold will stay until next reload of document (will implement some dfold command later, to delete it)
• “tfold” will create temporary fold for the current selection, this fold will disappear again on unfolding

This should allow better vi mode integration, too, as vi is able to fold arbitrary regions, too. (There is an internal API to fold any KTextEditor::Range you pass in, which should allow to fold by regex and other ways, too, if somebody steps up to implement it.)

If you find glitches, please report them as bugs and please attach some file to reproduce, I am very interested to get this all in even better shape for KDE 4.11, be folding crashs a thing of the past.

P.S.

For all people not using folding at all, be happy, it no longer will crash you (and me), as it is a nop if no folding ranges are created by the user and some extreme cases got a speedup of 1000% because of less overhead, like VERY large C++ sources

If we look at the incoming bug reports, a lot still seem to be located in our code folding implementation.

The problem of the current code folding code, even after the GSoC rewrite of large parts, is that it is inter weaved with the syntax highlighting engine.

During highlighting, we try to build up some tree containing all folding start/ends. To accommodate languages that have indentation based folding like Python, we started to fake such starts/ends which are normally tokens like { or }. As these tree can be unbalanced and contain overlapping regions, the implementation is quiet complex.

Additionally, as the folding relies heavily on the syntax highlighting, which is done per document, it is impossible to have different folding per view.

After looking again at the code to solve some issues, it got more and more clear to me, that we need to restart that from scratch.

Instead of feeding the highlighting info into a tree, I started to implement text folding that just allows you to mark regions as folding ranges manually. Then internally a non-overlapping tree of ranges is created that uses our moving cursors to keep track of changes in the document. Each view will have an instance of such a tree, which allows to have folding per view.

These folds are only created on demand, e.g. if you decide to fold some region via selection + “fold” command. This already works quiet well in my Kate repository clone. The missing part is now the integration with the highlighting, that should use this well defined API to only create a folding region in the moment the user wants to fold it. In addition some API for the highlighters is needed to indicate that for some line there is the fold action. After that is done, I might consider to replace the current implementation with the novel one, which is btw. much easier to unit test (which is already done for most API primitives).

Btw., the work is done in this repository, if somebody wants to contribute, patches are welcome .P

In the recent months Kate saw quite some contributions from developers other than “the usual kate developers”. This is really cool, areas include more work on python plugins, a lot of bug fixing and fine tuning in the vi input mode, an improved python indenter, and more unit tests. Especially one unit test turned out to be immensely useful and resulted in a fix for the infamous “rangesForLine” crash (about 40 times reported). We even decided to backport this to KDE 4.10.2, so KDevelopers and Kile LaTeXers please keep an eye open on whether this has any side effects!

Basically, the unit test provided us with a valgrind trace. Since valgrind is a very useful tool for all developers, we’ll have a closer look at the valgrind trace:

==10276== Invalid read of size 4
==10276== at 0x62F2116: Kate::TextCursor::lineInternal() const (katetextcursor.h:134)
==10276== by 0x62F9035: Kate::TextBlock::updateRange(Kate::TextRange*) (katetextblock.cpp:572)
==10276== by 0x62F8C57: Kate::TextBlock::mergeBlock(Kate::TextBlock*) (katetextblock.cpp:522)
==10276== by 0x62EFAA1: Kate::TextBuffer::balanceBlock(int) (katetextbuffer.cpp:494)
==10276== by 0x62EF1B2: Kate::TextBuffer::unwrapLine(int) (katetextbuffer.cpp:298)
==10276== by 0x637BB9C: KateBuffer::unwrapLines(int, int) (katebuffer.cpp:292)
==10276== by 0x6359DE9: KateDocument::editRemoveLines(int, int) (katedocument.cpp:1321)
==10276== by 0x6359AD6: KateDocument::editRemoveLine(int) (katedocument.cpp:1293)
==10276== by 0×6357841: KateDocument::removeLine(int) (katedocument.cpp:732)
==10276== by 0x6394C6A: KateScriptDocument::removeLine(int) (katescriptdocument.cpp:513)
==10276== Address 0×14353470 is 96 bytes inside a block of size 152 free’d
==10276== at 0x4C2A44B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10276== by 0x62FDE4D: Kate::TextRange::~TextRange() (katetextrange.cpp:66)
==10276== by 0x6470B1E: KateOnTheFlyChecker::deleteMovingRange(KTextEditor::MovingRange*) (ontheflycheck.cpp:535)
==10276== by 0×6470657: KateOnTheFlyChecker::rangeEmpty(KTextEditor::MovingRange*) (ontheflycheck.cpp:489)
==10276== by 0x62FE641: Kate::TextRange::checkValidity(int, int, bool) (katetextrange.cpp:196)
==10276== by 0x62F6C84: Kate::TextBlock::wrapLine(KTextEditor::Cursor const&) (katetextblock.cpp:168)
==10276== by 0x62EEF1D: Kate::TextBuffer::wrapLine(KTextEditor::Cursor const&) (katetextbuffer.cpp:231)
==10276== by 0x637BA6D: KateBuffer::wrapLine(KTextEditor::Cursor const&) (katebuffer.cpp:275)
==10276== by 0x635972E: KateDocument::editInsertLine(int, QString const&) (katedocument.cpp:1246)
==10276== by 0×6357690: KateDocument::insertLine(int, QString const&) (katedocument.cpp:706)
==10276== by 0x6394C32: KateScriptDocument::insertLine(int, QString const&) (katescriptdocument.cpp:508)

The trace tells us that somewhere in TextCursor::lineIntern() we read a variable/address that is invalid. In fact, we are reading a pointer called m_block that should be valid. In this case, as we know the pointer should be valid, we can conclude that the entire TextCursor object is then corrupted/invalid. Since the cursor is part of a TextRange, it means the TextRange is already invalid. Interestingly, this is exactly what valgrind is telling us in the lower part: The TextRange destructor that lead to the invalid read above is called in the 2nd half of the valgrind trace. From this, we can conclude that the function KateTextBuffer::mergeBlock() accesses a dangling pointer to a TextRange.

That’s a good start, but in fact, this is where the hard work begins. I’ve invesed about 2 hours to find that probably the dangling pointer is in a cache that is supposed to make the access of the TextRanges (MovingRanges to be precise) faster. Christoph then looked into it and tried several attempts to fix the nasty bug, finally showing us that the cache was indeed wrong but due to a too-late fixup of the start/end text cursors with respect to the TextBlocks. In total, Christoph probably invested about 6 hours, and given that Gerald certainly took quite a lot of time too to write the unit test, we probably have more than 10 ours just to get this bug fixed. Still, the good news is that we got it! And if we are lucky, this was the last bug in  Kate’s text buffer. So on to the next crashes… Help welcome!

I was a long time Vim holdout and often wondered to myself, “just why do those nutheads use vim?” until I googled and read the blog I just linked. After trying Vim out for a few days, I was completely hooked, but didn’t want to leave KDevelop with its awesome Intellisense/ code completion/ navigation features. Thankfully, Kate has a Vim mode, so I could get the best of both worlds

However, I’d often run into small but jarring inconsistencies with Vim, or sometimes find missing features, and so I set about trying to fix as many as I could. Since these were usually very small and unimportant things, I’ll just go ahead and list them, Graesslin-style

Vim mode is one of those rare and happy pieces of code which you can very easily write tests for: just add the starting text; the list of keypresses; and the expected, final text. Kuzmich Svyatoslav wrote a big battery of them a while back, and my first ever patch was an incredibly trivial little one that fixed a hole in the test framework and a bug that the hole obscured.

After that, I:

• Improved the test framework to enable us to test Insert Mode features;
• Fixed the inner curly bracket text object to be more like Vim (rather than deleting everything between the curly braces on a diB, Vim usually attempts to leave the closing curly bracket on its own line);
• Added { and } motions to Visual Mode;
• Fix a few bugs with Erlend’s very handy “comma text object” extension;
• Fixed numerous bugs with t/T and , & ; involving them getting “stuck” behind occurrences of the character to search for, and also made them “counted” so that one can do e.g. 3ta, and also mirroring Vim’s behaviour where if we can’t find the required count of characters on the line, we don’t move at all;
• Stopped the transition from Visual Mode to Normal mode from resetting the cursor position if we exited via ESC or Ctrl-c;
• Fixed a bug with the nifty “block append” feature;
• Fixed a nice bug with replaying the last command via . when the last command was an insertion that had a Ctrl-o in the middle of it (all the characters after we exited the Ctrl-o were treated as commands, with predictably zany results!)
• Ensured that the bracket text object worked in Visual Mode;
• Made the very handy Key Mapping feature “counted”, so you could perform your chosen Mapping several times in a row, and also made them count as one edit that could be reverted with just one request to Undo;
• Made p & P move the cursor to the end of the pasted text instead of leaving it at the beginning (whoops!), and similarly for gp/gP which places the cursor one past the end, hopefully respecting Vim’s slightly obscure exceptions and corner cases (e.g. p and P act as gp and gp when in Temporary Normal Mode);
• When doing Ctrl-o in Insert Mode, move the cursor back one step if we are at the end of the line;
• Try to keep the length of the number under the cursor unchanged on Ctrl-x and Ctrl-a and also don’t let the cursor stray off the number;
• Respect Vim’s rules for counting with Ctrl-x and Ctrl-a, especially with repeats;
• Fix a lovely bug with some of the key parsing where the repeat last change command did not work after a Ctrl-a;
• Made inserts (i, I, a, A, o, O and block append) counted, so you can do e.g. 100oHello, World!<ESC>, although I now see that the old implementation of counted o and O was “by design”. Oops – I’ll have to sort that out at some point :/;
• Make Ctrl-c reset the parser so that e.g. d<Ctrl-c> aborts the deletion. This one was cool as it remained undetected for ages by a sheer fluke: the only visible signs were that after doing e.g. d<Ctrl-c>, the cursor would stay at half size, and also another bug that I had been promising myself I’d investigate for a while: typing r<Ctrl-c> would replace the current character with a nonsense character, which turned out to be the representation of the keypress Ctrl-c!;
• Fixed a few minor flaws where after e.g. osometext<ESC>, we would have to request an Undo *twice* before getting back to where we issued the command;
• Arranged for a return to Normal Mode if we Ctrl-c or ESC when in Temporary Normal Mode. Vim is weird, here: its behaviour is just as you would expect if you were in Normal Mode, but the status bar still claims we are in Insert Mode!
• Fixed a bug where issuing y% would actually move the cursor as well as yanking the text;
• Added the last edit markers, [,] and .;
• Fixed a few bugs with inner bracket text objects being treated as invalid if there were less than three characters long;
• Respected Vim’s rules for the [[, ][ etc motions when used with commands: they behave slightly differently than when they are used as cursor motions;

and that’s about it! Kate Vim’s testability make it very pleasant to develop features/ fixes Test First, so all of these are buttressed by a decent amount of automated tests.

The Future

I’m nearing the end of the papercuts stuff, and will shortly move onto slightly larger scale things. This will consist of implementing a Vim-style search and replace bar, with all the usual Vim shortcuts: Ctrl-c to dismiss; Ctrl-r to insert contents of register; Ctrl-rCtrl-w to insert the word under the cursor; etc, and with proper Vim style searching e.g. positioning the cursor on the first letter of the current match; return to where we were if cancelled; interactive search and replace with Y/N/Q/A; etc. I think I’ll use “smartcase” for deciding case sensitivity, but might make this configurable through a hidden config option if there is any demand for it.

There’s currently quite a lot of Vim-specific code that has leaked into Kate’s own Find/ Replace dialog, and I’d really like to be able to delete that and just have Vim use this Vim-specific version. What do people think? I’d have to get it at least as functional as Kate’s own one before I’d consider this, so we’d need e.g. some way of going through the Find and the Replace history separately (I don’t think stock Vim can do this?) and easily toggling whether this is a regex or a literal search, etc. I’d really like some feedback on this, and a suggestion for shortcuts etc!

Done properly, this would give us a powerful, keyboard-friendly Find (and Command Line) dialog where we can easily track the keypresses, which would set us up nicely for the next major task – Vim Macro support!

Before all that, though, I just have a couple of smaller odds and ends to sort out: I need to get auto-completion properly working with . (currently, if auto-completion is automatically invoked, pressing . won’t include the completed text), and it would be nice if Ctrl-p and Ctrl-n could wrap around in the list of completions as they do in Vim (need to sort out a Kate bug with completion first). I also have an another idea which I’d like some feedback on; it would be nice if people would try it out and let me know if they find it helpful, annoying, etc. If only there was a way of letting people test out a patch that hasn’t been committed yet … ! Which leads nicely on to:

emscripten-kate

You may have seen my blogs on emscripten-qt, a port of Qt to Emscripten, an awesome technology that allows one to compile C/C++ to Javascript. This caught the eye of Mozilla, who were looking for an example of a “serious” app to go along with the games and utilities in their current list of Emscripten demos, and they kindly offered to sponsor me to work on this. After looking through a list of candidate apps, they eventually suggested porting Kate: not exactly an easy task, as Kate obviously requires not only a big chunk of kdelibs (with its reliance on DBUS and external processes like kded, etc) but also QtScript for its extensibility (the automatic code indentation for various programming languages, for example, is implemented in JS) meaning I’d need to get a C++-based Javascript interpreter ported to Javascript

This ended up being not as hard as I feared, and now we have a decent (though very cut-down; there are no plugins, so it’s more like KWrite than Kate ) version of Kate ported to Javascript. I’ve merged in the patch I’d like feedback on as mentioned above so you can easily try it out as long as you have a modern browser, plenty of bandwidth (even after server-side compression, you’re still looking at a tens of MB download :/) and also plenty of free RAM and CPU. There’s an unfortunate bug in Chrome which means you’ll need to use the no icons version, alas. Konqueror and reKonq also do not work, to my knowledge. Let me know what you think, and if anyone has any thoughts on shortcuts for the extended Find/ Command Line bar, do let me know!

Okular, KDE’s universal document viewer, has a really cool feature I’m using for years already: “Go > Forward” and “Go > Backward”. These two actions allow to quickly jump to positions in the document where you came from in a chronological order. Consider e.g. reading the phrase “As shown in [15], …”, and you want to know quickly lookup reference [15]. So you click on it, and okular will jump to the list of references. And “Go > Back” will bring you back to exactly the position where you came from.

Awesome

In fact, I removed the “Previous” and “Next”-page buttons from the toolbar in favor of the “Back” and “Forward” feature, which is much more useful to me Given that my colleagues were not aware of this feature (all experts in LaTeX  and all using Kile and Okular), I thought to praise it here in a dedicated blog. Interestingly, the Okular Handbook is missing this feature. Any takers to fix this? Update: This is also mentioned in the Okular handbook

In 2012, Kate had a GSoC project with the aim of adding a Scripting IDE plugin. The idea was to make it easy to write Kate Part scripts (command line scripts, indenters), that should include rudimentary code completion and a gui to manage available scripts. As detailed in the blog post, a rudimentary list that showed all available scripts is available. However, due to changes in Kate Part’s scripting framework (e.g. changes in the folder structure, require() function to load libraries), the plugin in its current form is not applicable anymore. Still, the idea of having a better JavaScript support is valid.

So this blog post is about some ideas how we can add possibly really cool JavaScript support to Kate as a plugin. This plugin should provide the following features:

1. provide code completion
2. support for loading additional modules (jQuery, Node.js, Prototype, Kate Scripting API, …)
3. specialized support for Kate Part scripting
4. outline in terms of a function and prototype browser

JavaScript Code Completion

Providing code completion to JavaScript requires a parser so we have an abstract syntax tree (AST) of the current file. This parser needs to be error-tolerant, since during the process of programming, the source code often violates the syntax. Searching the Web, relatively few information about such a parser exists. But one tiny parser shines: Esprima (source code, more info), written by KDE’s “very own” Ariya

Esprima is a JavaScript parser written in JavaScript. It is (to some degree) error-tolerant and returns an AST as shown in the parse demo. The AST is returned in simple JSON syntax, meaning it can be easily parsed with either the JavaScript JSON functions or JSON in Qt5 (JSON for Qt4). Along the error-tolerant mode, the AST returned by Esprima also contains comments and line/column information, if desired.

Interestingly, the idea of using Esprima for code completion arose about a year ago, and meanwhile there are several projects that successfully use the Esprima AST: Eclipse Orion, a web-based IDE, uses Esprima for code completion and for the outline view (sources). The source code for the code completion is available in the orion client git module: lib, code completion (content assist), unit tests.

So What Next?

As it seems the code is all there, the next step would be to start a small standalone project and write a proof of concept to check whether this approach is feasible. I’d suggest to use Qt’s JavaScript interpreter (QtScript in Qt4, QJS in Qt5). In the long run, the goal would be to have code completion and possibly an outline view. If this works, more functionality like support for Kate Scripting could be added. So there is a lot to play around with.

If you are interested, just start working on it. It might be a good GSoC project (although we’d require a quite skilled developer here) Thoughts? Comments?

Now the statistics of the kate.git are online for public viewing.
They will be updated daily, located on: http://kate-editor.org/stats/

Unfortunately, the statistics of the last years are not that “representative”, as the moves of Kate around in SVN and to Git biased the statistics, as I did a lot of the commits for syncing and moving and so on.

Still it is amazing how MANY people did contribute during Kate’s history! (see Kate Authors)

A big THANK YOU to all contributors that appear there (and all the people that provided patches others merged in, did the testing, bug reporting, translations, …).

(And thanks to the authors of git_stats.)

The Projects plugin in Kate just gained a context menu for the tree view that shows several git tools, if available:

Clicking will open the corresponding application in the correct working directory. Currently, only gitk, qgit and git-cola are supported. If you want more git integration, you probably have to use KDevelop or QtCreator

The project plugin in kate.git master now has four new more plugins, with many features in each one: Python (autocomplete, smart snippets, parse checker, pep8 checker and pyflakes checker), Javascript (autocompletes, jquery snippet, pretty JSON, and jslint checker), Django (smart snippets and utils to Django template) and XML (pretty xml). There are also many generic functions and generic classes in these that will be useful to the new plugins developers.

I began to develop these plugins in 2009, this was my first version :-). I wanted to set a shortcut to a snippet, as it was not possible (now it is posible) I started to develop these plugins to Kate.

In November 2011, I created a repository on github to develop new features and share them. I have to thank Alejandro Blanco, Jeroen van Veen, Javier Romero, Martin Borho, Justin Chudgar and Yaco Sistemas for helping me in this project.

In October 2012 Christoph Cullmann (Kate maintainer) sent me an e-mail, in which he asked me if I was interested to contribute with KDE project. I answered: “Of course!”…. finally I have a little time, and I have been able to integrate these plugins in the kate.git

Features to Python Plugin:

• Python dynamic autocomplete using pyplete, this is in beta… It requires development, but now it is very useful.
• Smart snippets:
  1. Insert an __init__ method into a class.
  2. Insert a super call into a method.
  3. Insert a call recursive into a method or into a function
• Simple snippet: Insert the debug instrunctions “import ipdb; ipdb.set_trace()”
• Checkers: When you save the file it is syntax checked, pep8 checked and pyflakes checked. You can invocate them any other time.

Python auto complete

Features to Javascript Plugin:

• JavaScript static autocomplete, using a JSON file.
• JQuery static autocomplete using a JSON file.
• Pretty JSON: Pretty format of a JSON code selected
• JSLint checker: When you save the file it is JSLint checked. You can invocate it any other time.
• JQuery snippet, insert the ready code of the jQuery

JSLint checker

Features to Django Plugin:

• Smart snippets:
  1. Create a model class
  2. Create a form class
  3. Template to the urls.py file
• Simple snippet: Insert the typical imports of a views.py file
• Template Django utils
  1. Insert the tag block/endblock. The name of the block will be the text selected
  2. Close the last templatetag open

Create a form class

Pretty XML:

Pretty format of an XML code selected

Pretty XML

Generic features:

Also I have added many generic functions and generic classes, likely the more outstanding are the autocompletations. Now you can create a code completion model with very few lines:

import kate
from libkatepate.autocomplete import AbstractJSONFileCodeCompletionModel, reset

class MyCodeCompletionModel(AbstractJSONFileCodeCompletionModel):

    MIMETYPES = [] # List of mimetypes E.G.: ['application/javascript', 'text/html']
    TITLE_AUTOCOMPLETION = "My Auto Completion Model"
    FILE_PATH = 'my_autocompletion.json'
    # Operators to separate the instrunctions
    OPERATORS = ["=", " ", "[", "]", "(", ")", "{", "}", ":", ">", "<",
                 "+", "-", "*", "/", "%", " && ", " || ", ","]

@kate.init
@kate.viewCreated
def createSignalAutocompleteJS(view=None, *args, **kwargs):
    view = view or kate.activeView()
    cci = view.codeCompletionInterface()
    cci.registerCompletionModel(my_code_completion_model)

my_code_completion_model = MyCodeCompletionModel(kate.application)
my_code_completion_model.modelReset.connect(reset)

The my_autocompletion.json file should have this format:

  {
    "xxx": {
      "category": "module",
      "children": {
        "www": {
          "category": "class",
          "children": {}
        },
        "yyy": {
          "category": "constant",
          "children": {}
        },
        "zzz": {
          "category": "function",
          "args": "(x1, x2, x3)",
          "children": {}
        }
      }
    }
  }

I encourage you to participate in the KDE project, for me this participation has been very simple because this community is very, very open.

Thanks all,

As a quick notice: The highlight selection plugin was not removed in KDE SC 4.10.0. Instead, a silly bug results in not loading the plugin. This is fixed for DKE 4.10.1. If you cannot wait, you can find a workaround here

The project plugin in kate.git master has now the ability to call cppcheck.

This is just hacked in at the moment and needs more love, but it works.
Feel free to contribute integration of other code checkers, cppcheck is only the first, I hope