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....

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....

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....

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 ;=)...

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....