Kate | Get an Edge in Editing

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.

As you can read in the official Creator 4.9.0 release announcement, Qt Creator now uses the KSyntaxHighlighting Framework for providing the generic highlighting.

This is a nice step for the wider adoption of this MIT licensed part of the KDE Frameworks.

And this is not just an one-way consumption of our work.

The framework got actively patches back that make it more usable for other consumers, too, like Kate ;=)

If you want concrete examples, take a look at:

• D18982: prevent assertion in regex load
• D18996: Fix building with namespaced Qt
• D18997: Add functions returning all definitions for a mimetype or file name
• D19200: Return sorted definitions for file names and mime types
• D19215: Install DefinitionDownloader header

I hope this cooperation will continue in the future. I thank the people working on Qt Creator that made this integration possible. I hope the initial effort will pay of with less code for them to maintain on their own and more improvements of the framework for all users.

Today I did run again into an old problem: You need to archive a lot small and large files inside a single Git repository and you have no support for Git LFS available. You did this several year and now you ended up in a state where cloning and working with the repository is unbearable slow.

What now? Last time I did run into that, I archived the overfull repository to some “rest in peace” space and used git filter-branch to filter out no longer needed and too large objects from a repository copy that then will replace the old one for daily use.

There are a lot of guides available how to use git filter-branch for that. All variants I ever used were complex to do and did take very long. Especially if you need several tries to get a sane set of stuff you want to remove to gain enough space savings.

This time, I searched once more and stumbled on the BFG Repo-Cleaner. And yes, it does what it promises on the web site and it seems to be trusted enough to be advertised by e.g. GitHub, too.

Just following the steps described on their landing page allows to shrink your stuff nicely and without a lot of round-trip time.

If you still are just in the “experimenting” phase to see which space decrease one can archive with which file size filter (or which files you want to purge by removing them from master before running the tool), I recommend to swap the step

git reflog expire –expire=now –all && git gc –prune=now –aggressive

with just

git reflog expire –expire=now –all && git gc –prune=now

to not wait potential hours for the aggressive GC. For me that was good enough to get some estimate of the later size for my experiments before I settled to some final settings and did the real run.

And as always, if you touch your Git history: Do that only if you really need to, keep backups, check carefully that afterwards the repository is in some sensible state (git fsck --strict is your friend) and inform all people using that repository that they will need to do a full new clone.

During my web site upgrade, I reviewed the old stuff I had hosted on my long gone web sites but still archived here locally. An interesting thing I stumbled on are the KDE 3 -> 4 porting screenshots of Kate I saved in 2005.

They actually show pretty nicely how far we have gone since 2005 with our development stack.

The KDE 3 -> 4 transition was a large hassle. It did take weeks of work just to get Kate back into an usable state.

We first started with some trivial KTextEditor container (a mini KWrite) for the porting to get KTextEditor at all doing something. That started out with something that even had no menu or toolbars working:

This evolved after two days into a kind of working KWrite port (icons still randomly missing):

After the KTextEditor part did work “reasonable”, we started with Kate:

And ended up with an initial ported prototype three days later:

And after that a long time of actual polishing for KDE 4.0 did start. Kate was actually one of the first ported applications during the KDE 3 -> 4 transition.

The KDE 4 -> KF5 transition was much nicer, even thought the Frameworks split did cost a lot of time and resources. But the actual changes to the application code bases were not that radical.

And where did we end up with this ~14 years later? Actually, just here:

It is still recognizable the same application, thought I hope some progress is visible :=)