Category Archives: Developers

Current State of Kate on 5

Just a quick update on the frameworks 5 port: KTextEditor,  Kate Part and KWrite build and run. Kate is not yet ported and does not compile. These changes were already committed:

  • made KTE::Cursor and KTE::Range non-virtual for maximum speed
  • removed KTE::EditorChooser, since Kate Part is the only implementation since over 10 years. Just use KTE::Editor* editor = KTE::editor(); to get KatePart.
  • new signal KTE::Document::readWriteChanged()
  • removed KTE::LoadSaveFilterCheckPlugin, was unused since years
  • removed all KTE::Smart* classes in favor of KTE::Moving* classes
  • merged KTE::CoordinatesToCursorInterface into KTE::View
  • new: KTE::Range KTE::Document::wordRangeAt(KTE::Cursor)
  • new: QString KTE::Document::wordAt(KTE::Cursor)
  • new: KTE::DocumentCursor
  • ported lots of KSharedPtr to QSharedData
  • updated Mainpage.dox to reflect porting notes
  • some small interface cleanups and additions

Please feel free to join the porting fun. Just follow the Frameworks compile guide and checkout the git branch “frameworks” in the Kate git module.

Kate: “C++/boost Style” Indenter

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.

Small example:

typedef typename boost::mpl::fold<
    typename boost::mpl::transform_view<
        Seq
      , boost::remove_pointer
      >::type
  , boost::mpl::long_
  , boost::mpl::eval_if<
        boost::mpl::less
      , boost::mpl::_2
      , boost::mpl::_1
      >
  >::type type;

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.

// Inheritance list formatting
struct sample
  : public base_1
  , public base_2
  , ...
  , public base_N
{
    // Parameter list formatting
    void foo(
        const std::string& param_1                      ///< A string parameter
      , double param_2                                  ///< A double parameter
      , ...
      , const some_type& param_N                        ///< An user defined type parameter
      )
    {
        // Split `for` parts into few shorter lines
        for (
            auto first = std::begin(param_1)
          , last = std::end(param_1)
          ; it != last && !is_found && !is_exit_requested
          ; ++it
          )
        {
            auto val = check_some_condition()
              ? get_then_value()
              : get_else_value()
              ;
        }
    }
};

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
    // Before pressing ENTER at position marked by '|'
    some_call_with_long parameters_list(|param1, ..., paramN);  // Comment starts here...
    // After pressing ENTER: keep comment at the original line
    some_call_with_long parameters_list(                        // Comment starts here...
        |param1, ..., paramN);

    Also try to use _ENTER_ in the middle of a comment text ;-)

  • 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:
    #define PP_FORM_A_ROW(State, Data, Elem)    \
      {                                         \
        {                                       \
            field_path(                         \
                BOOST_PP_TUPLE_ELEM(2, 0, Data) \
              , BOOST_PP_TUPLE_ELEM(2, 1, Data) \
              , BOOST_PP_TUPLE_ELEM(2, 0, Elem) \
              )                                 \
          , BOOST_PP_TUPLE_ELEM(2, 1, Elem)     \
        }                                       \
      , manage_config_keys::action::GET         \
      },
  • * typing `R”` will initiate a raw string literal

This advanced indenter  has some other (smaller) features to reduce typing. Hope, you’ll like them if found! ;)

PS: The other things I’ve found useful when typing C++ code can be plugged with some Python plugins dedicated to C++.

KatePart/KWrite arrives in the KDE Frameworks 5 world

After starting the “frameworks” branch in kate.git more than a week ago but doing not much beside an initial KTextEditor compile & link port I felt a big guilty ;)

Given a lot of people blog about the progress of programs X and Y for Qt 5.2 and KDE Frameworks 5 I guess it is time that KatePart joins this club.

Some hours later, a ‘working’ version of KatePart and KWrite have landed in the “frameworks” branch of kate.git. KWrite launches, loads the part and the open action even works (command line parsing is off-line btw. ATM).

From the let it run ;)   commit on, KWrite should at least launch and open files via file dialog and here is the mandatory screenshot (a KDE Frameworks 5 KWrite over an Kate 4.x window):

I marked all places where I commented stuff out or did a hack with “FIXME KF5″ in a comment or “#if 0″ region. Help welcome, Kate application still to be ported ;) But please mark your “hacks” in the same fashion, otherwise, we will never find them again.

To remember the history, the initial KatePart KDE 4 port happened more than 8 years ago, here a screenshots of that time (2005-05-15):

I think the first KDE Frameworks 5 version looks a bit better. Thanks a lot for all the people getting both the kdelibs frameworks branch in such good shape and all the contributors to Qt 5.x!

The Kate team will do its best to make the KDE Frameworks 5 version of Kate as popular as the 4.x variant is.

KDE Frameworks 5 & Kate, let the fun begin :)

After thinking some days about how to tackle the 4.x => 5.x transition in Kate (KTextEditor/Part/Application) and the nice “what we should do” blog by Dominik, I think the time for fun is there.

Therefore I started to port our stuff to KF5 in the “frameworks” branch.

The basic idea would be: get it compiling and running.

Then we can decide if the frameworks branch is a mere “hack to see if it works” experiment which can be later used to port master without a lot of work or if we say “ok, works kind of well” and we just switch development over for new features from master to frameworks and with that from 4.x to 5.x.

The KTextEditor interfaces compile now, KatePart should be the next thing to tackle.  Then KWrite and Kate.

Happy hacking ;)

(To get a working KF5 development environment, just follow this howto.)