After the initial porting of KTextEditor interfaces and KatePart, now the Kate application itself runs on KF5, too.
It still has a LOT of issues (and I marked all commented out pieces with FIXME KF5), but at least, it launches and loads the essential file tree plugin and allows you to open files via the “Open” action. Any help in fixing the remaining issues is welcome (and removing deprecated cruft), but keep in mind, it might eat all the files you edit 🙂

That means now all stuff in the “frameworks” branch of kate.git beside the “addons” directory containing plugins/plasma stuff at least compiles and launches with KF5.

Now the question is how we handle further development. Shall we switch to “frameworks” for all major stuff in interfaces/part/application and only let feature work be done in the “master” branch for addons (which we then can port later on)?

Greetings from the Kate land again. This time, Alex Turbov will spend a few words about his “C++/boost Style” indenter that is part of Kate Part for several releases.

The Initial Motivation

This indenter (initially) was designed to help code typing in a “boost::mpl” style (i.e. with leading comma in formatted (template) parameters list). One may read the rationale of such approach in the “C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond” by David Abrahams and Aleksey Gurtovoy. It is really easy to miss a comma when invoke metafunctions and it usually leads to a lot of complicated compile errors. The indenting technique should help to visualize the control syntax and prevent stupid errors like missed commas.

In practice I’ve noticed that this style can be used to format long function calls or even `for` statements. Actually everything that can be split into several lines could be formatted that way. And yes, it is convenient to have a delimiter (comma, semicolon, whatever) as a leading character to make it visually noticeable.

It looks unusual for awhile 🙂 but later it becomes (quite) normal and easy to read and edit 🙂 Really! When you want to add one more parameter to a function declaration it takes less typing if compare to a “traditional” way 🙂 (especially if you have some help from an editor, like move/duplicate the current line or a selected block up/down by a hot-key or having an indenter like this 🙂

Next improvements was designed to simplify typing C++ code, using most common syntactic rules, like:

add spaces around operators and after a comma

add space after control keywords, but not after a function name in a call expression

etc.

Further improvements bring to the indenter some cute features and nowadays I’d prefer to consider it similar to a T9 (input method) for C++ coding, but not as a “real indenter” in contrast to others, shipped with kate out of the box 🙂 Particularly this indenter “exploit” can see “impossible” syntax and (try to) transform it to something “reasonable” — i.e. just like T9 it tries to be a predictive.

For example, if you have autobrackets plugin turned ON, when typing `some(nested(` gives you `some(nested(|))` w/ `|` indicating a current cursor position. If you press `,` at this position, it gives you the following snippet `some(nested(), |)` supposing that you want to add one more parameter to a `some()` call. While typing `;` looks like you’ve done with that nested calls and gives you the `some(nested());|` snippet. Both cases help you to avoid couple of redundant key presses 😉

… but do not even try to use this indenter to (re)format blocks of code! 🙂 It can do some really simple/primitive formatting, but far from good — as I’ve mentioned above: this “not quite indenter”™ designed to help you to __”do little more with less typing”__ for C++ 😉

Some of the Features

to start a C-style comment block type `/*` and press ENTER key — it gives you

/*
* |
*/

to start `doxygen` comment block use `/**` + ENTER. Every following ENTER just extend the current block.

to start C++ style comment just type `//` it will add a one space after 😉

I prefer to have on-line-comments (i.e. C++-style comments after some expression) to be aligned at 60th position. So typing `//` will automatically move comment to that position if there was some code before. Moreover the indenter tries to keep that comments when you use ENTER key to break some complex expressions into a few lines

typing `///` gives you `/// ` (with a space) or `///< ` depending on presence of code at the current line

from time to time I use grouping in a doxygen documentation, so typing `//@` gives you:

//@{
|
//@}

always add a space after `,` character — simple, but really convenient! really soon you’ve stopped typing a space after any comma and feel yourself inconvenient with other indenters 😉

typing `<` without a space after some identifier adds a closing angle bracket (like notorious autobrackets plugin do for other bracket types), because template instantiation guessed. So typing `std::vector<|` gives you `std::vector<|>`. But `std::cout<|>` turns into `std::cout << |` after pressing one more `<` 😉

a lot punctuation characters being typed withing parenthesis is a some operator (or at least part of), so will be moved out of parenthesis (most likely call expression). Try to type various punctuators at marked position in the following snippet `some(|)`…

typing a backslash in on a line of a long `MACRO` definition cause realign all others to fit to a longest line: