Kate | Get an Edge in Editing

Two days ago I mentioned here that the bug report count of KTextEditor and Kate has risen to some not that manageable amount.

For developers that report a bugs or wish, the best way to really get it solved is to scratch your own itch and provide some patch.

I know this is not feasible for all bug reporters, as not all are developers nor will even the developers all have either time nor perhaps the right skill set to tackle the issue on their own.

But if you have the time and you are at least a bit familiar with C++/Qt, you should give it a try.

We can help you to get your patch done, that is much easier for e.g. myself than to motivate me to work on a bug or wish that doesn’t concern my normal workflow or lie within my skill set.

For example we have a lot of issues with left-to-right text rendering or related to languages that use complex Unicode surrogates. Given I have zero knowledge of any language using this my motivation to dig into these issues is small (and I will more likely break more things than fix them).

The same holds for issues in our Vi mode. I don’t use this mode myself nor do I really know how Vi commands shall behave in real life. Therefore any fix or enhancement there is beyond me.

A good example for such a “Scratch Your Own Itch” approach is bug 407910.

It is a small request, to have some action/shortcut to reset the font size to the default one. We have since years some zoom in/out actions/shortcuts but nothing to go back to the configured one.

I rarely use the zoom stuff, perhaps once in a month, if I want to show something to a colleague on my screen or projector and it is really not readable with my normal font size. Therefore my motivation to invest any work into yet an other action I will not use regularly is small.

But, in this case, the reporter had the time to invest a bit work into this.

He provided a patch via our KDE Phabricator - D21412.

We needed some iterations to get the patch into a usable shape in the bug report and in Phabricator, but thanks to the persistence of the reporter, it got now pushed to our repository.

If nobody would have stepped up to provide at least some initial patch for this, such a request for sure would have rotted again in our bug database.

This is not the first time such a nice thing happened, this is just a recent example how such things can work out.

Therefore, if you report something and are capable of given it a try on your own, please do so!

Perhaps even some of the existing bugs or wishes are stuff you want to take care of yourself because they concern you!

I think not a lot motivates your more to do something than an issue you have with a tool for your workflow. At least for me that was the reason to at all start the development of Kate (I missed a MDI variant of KWrite) and join the work on stuff like KTextEditor.

The bug report count of KTextEditor (implementing the editing part used in Kate/KWrite/KDevelop/Kile/…) and Kate itself reached again some value over 200.

If you have time and need an itch to scratch, any help to tackle the currently open bugs would be highly appreciated.

The full list can be found with this bugs.kde.org query.

Easy things anybody with a bit time could do would be:

• check if the bug still is there with current master builds, if not, close it it
• check if it is the duplicate of a similar still open bug, if yes, mark it as duplicate

Beside that, patches for any of the existing issues are very welcome.

I think the best guide how to setup some development environment is on our KDE Community Wiki. I myself use a kdesrc-build environment like described there, too.

Patches can be submitted for an review via our KDE Phabricator.

If it is just a small change and you don’t want to spend time on Phabricator, attaching a git diff versus current master to the bug is ok, too. Best mark the bug with a [PATCH] prefix in the subject.

The team working on the code is small, therefore please be a bit patient if you wait for reactions. I hope we have improved our reaction time in the last months but we still are lacking in that respect.

The Kate lsp branch contains now the infrastructure as used by Qt Creator. In addition, clangd is now somehow started in a working state for the first project opened inside Kate.

For example, if you use the CMake Kate project generator and you compile Kate from the “lsp” branch, clangd should pick up the compile_commands.json for a CMake generated Kate project.

;=) Unfortunately not much more than starting and informing clangd about the open workspaces (for the first opened project) works ATM.

If you press ALT-1 over some identifier, you will get some debug output on the console about found links, like below:

qtc.languageclient.parse: content: “{\“id\”:\“{812e04c6-2bca-42e3-a632-d616fdc2f7d4}\“,\“jsonrpc\”:\“2.0\“,\“result\”:[{\“range\”:{\“end\”:{\“character\”:20,\“line\”:67},\“start\”:{\“character\”:6,\“line\”:67}},\“uri\”:\“file:///local/cullmann/kde/src/kate/kate/katemainwindow.h\“}]}”

The current ALT-1 handling is a big hack, as then one just adds the current document and triggers the GotoDefinitionRequest. A proper implementation tracks the opened/closed documented of the editor.

But at least in principle Kate is now able to start some language server processes and talk a bit with them, all thanks to the nice code borrowed from Qt Creator.

:=) As my spare time is limited, any help in bringing the branch up-to-speed is highly welcome, just drop us a mail to kwrite-devel@kde.org or mail me in private (cullmann@kde.org). A working LSP integration will help to make Kate more attractive for programmers of many languages.

The Language Server Protocol (LSP) allows the integration of stuff like code completion, jump to definition, symbol search and more into an application without manual re-implementation for each language one wants to support. LSP doesn’t fully allow an integration like KDevelop or Qt Creator do with the libclang based tooling aimed for C/C++ but on the other side offers the possibility to interface with plenty of languages without a large effort on the client side.

If one takes a look at some current LSP clients list, a lot of editors and IDEs have joined the LSP family in the last years.

In the past I was always scared away to start implementing this in Kate, as no readily available library was around to do the low-level work for the client. Whereas you get some reference stuff for the JSON based protocol for JavaScript and such, for Qt nothing was around.

Fortunately Qt Creator started to implement an LSP client beginning with the 4.8 release.

Based on this code, I started now to get this into the Kate project plugin. At the moment not much more has happened then some initial import of the Qt Creator LSP infrastructure code into the Kate lsp branch.

If I get this working (help is welcome!), any improvements will be submitted back to the Qt Creator implementation. If it really starts to work well in Kate, one might think about some better code sharing in the long term. But before such plans, first at least some basic things must work for some initial language server like clangd.