Coming in 4.13: Improvements in the build plugin

Kate comes with a build plugin, which supports running make, or ninja,  or actually any arbitrary command directly from within Kate. This is obvisouly  useful when using Kate as development editor, and this plugin has seen several improvements for the 4.13 release.

A small change, but for affected developers a major improvement, is that Kate  can now parse warning and error messages from the Intel compilers, icpc and icc.
So for those of you using icpc, Kate can now automatically jump to the line of code which caused the error. Actually you don’t have to wait for 4.13 for this, it is already available since 4.12.3.

Beside that, there are improvements which benefit all users of the build plugin. Let’s start with a screenshot, which already shows one of the major changes.

kate-targets
Build plugin showing the list of targets and the Build-menu

 

Up to 4.12, it was possible to create multiple “targets”, and each of these targets could contain a “Build” command, a “Clean” command and a “Quick” command.  As of 4.13, the build plugin is not limited anymore to these three commands. As can be seen in the screenshot, every “target set” can now  contain an arbitrary number of actual targets.
They are listed in a table widget. To add a target, click the green “plus”-button in the lower right. This will  append a target to the end of the list. It can be edited by simply double clicking it (or pressing F2 while keyboard focus is in the table).
To delete a target, click the “minus”-button right next to the “plus”
One of the targets can be marked as the “default” target. This will typically be  the target which runs “make all”. Additionally one target can be marked  as the “clean” target, this will typically be “make clean”. For these two special  targets separate keyboard shortcuts can be assigned, so they are always  quickly available.

A whole set of actions which can be bound to shortcuts can be seen here:

build-shortcuts
Configuring keyboard shortcuts for the build plugin

 

Now to the actually interesting part: building something.
There are multiple ways how to start building a target.

The default and the clean targets can be built directly using keyboard shortcuts, in the screenshot above I assigned F8 to the default target.
To build another than the default target, you can select the target you want in the table and then build it by clicking the blue “check”-button next to the “plus” and “minus” buttons.
For keyboard users, there is a quick-select dialog. It shows a list with the names of all targets, which can be filtered by typing part of the target name. That’s a really quick way to build any of the available targets. Here’s a screenshot:

kate-targets-quick-select
The Quick-select dialog for building a target

 

Once building has started, the output is displayed in the log view.
As can be seen, there is only one output tab left, where the “level of detail” can be adjusted using a slider. While building, the plugin automatically switches to the log display.

kate-build-log
Build plugin showing the output while building.

 

Also new, there is now a simple status display, which tells you which target is currently being built or was built previously.
Next to it, there is yet another way to start a build, the “Build again” button. Once some target has been built, using this button the same target can be built again. Oh, and there is now also a button to cancel a build, in case you forgot the assigned keyboard shortcut.

When building has finished, the output tab automatically switches to a parsed output mode, which lists the warning – and error messages. By double clicking on one of them or using the keyboard shortcut of your choice, I assigned F9,  you can jump directly to the line of code which caused the error.

kate-build-error
Build plugin showing the parsed errors after the build failed.

All that together, should make the build plugin even more useful than before.
Have fun compiling ! :-)

Alex

Kate Part (KF5): New Default Styles for better Color Schemes

Kate Part gained 17 new default styles in addition to the existing 14 default styles. These changes are available for Kate based on the KDE frameworks 5 initiative and currently live in ktexteditor.git module.

Default Styles are predefined font and color styles that are used by Kate Part’s syntax highlighting. For instance, Kate Part always had a default style for comments. Therewith, the comments in all syntax highlighting files look the same (by default, a gray color). Or keywords are by default always bold and black.

However, during the last years it became apparent that the list of 14 default styles were not always enough. Consequently, lots of syntax highlighting files defined their own hard-coded colors. For instance, doxygen comments were hard-coded in a dark blue color. The problem with hard-coded colors is that they do not adapt when changing the default styles. Hence, doxygen comments were barely readable on a dark color scheme.

Therefore, a discussion took place on kwrite-devel (thread 1, thread 2, thread 3) that ended in 17 new default styles and a categorization of these as follows (the new default styles are bold):

Category “Normal Text and Source Code

  • dsNormal: default for normal text and source code.
  • dsKeyword: Used for language keywords.
  • dsFunction: Used for function definitions and function calls.
  • dsVariable: Used for variables, if applicable. Example: $foo in PHP.
  • dsControlFlow: Used for control flow highlighting, e.g., if, then, else, return, continue.
  • dsOperator: Used for operators such as +, -, *, / and :: etc.
  • dsBuiltIn: Used for built-in language classes and functions, if applicable.
  • dsExtension: Used for extensions, such as Qt or boost.
  • dsPreprocessor: Used for preprocessor statements.
  • dsAttribute: Used for attributes of functions or objects, e.g. @override in Java, or __declspec(…) and __attribute__((…))in C/C++.

Category “Strings & Characters

  • dsChar: Used for a single character.
  • dsSpecialChar: Used for an escaped character in strings, e.g. “hello\n”.
  • dsString: Default for strings.
  • dsVerbatimString: Used for verbatim strings such as HERE docs.
  • dsSpecialString: Used for special strings such as regular expressions in ECMAScript or LaTeX math mode.
  • dsImport: Used for includes, imports, modules, or LaTeX packages

Category “Numbers, Types & Constants

  • dsDataType: Used for data types such as int, char, float etc.
  • dsDecVal: Used for decimal values.
  • dsBaseN: Used for numbers with base other than 10.
  • dsFloat: Used for floating point numbers.
  • dsConstant: Used for language constants, e.g. True, False, None in Python or nullptr in C/C++.

Category “Comments & Documentation

  • dsComment: Used for normal comments.
  • dsDocumentation: Used for comments that reflect API documentation, e.g., the default style for /** */ comments.
  • dsAnnotation: Used for annotations in comments, e.g. @param in Doxygen or JavaDoc.
  • dsCommentVar: Used to refer to variables in a comment, e.g. after @param <identifier> in Doxygen or JavaDoc.
  • dsRegionMarker: Used for region markers, typically defined by BEGIN/END.
  • dsInformation: Used for information, e.g. the keyword @note in Doxygen.
  • dsWarning: Used for warnings, e.g. the keyword @warning in Doxygen.
  • dsAlert: Used for comment specials such as TODO and WARNING in comments.

Category “Miscellaneous

  • dsOthers: Used for attributes that do not match any of the other default styles.
  • dsError: Used to indicate wrong syntax.

Existing Syntax Highlighting Files

If the new default styles are not used, syntax highlighting files are backwards compatible to Kate Part in KDE SC 4. However, the plan is to use the new default styles where applicable to avoid hard-coded colors. To this end, the kateversion attribute in the language element will be set to 5.0 (yes, Kate Part’s version changed from 3 to 5 to match KDE frameworks 5) to avoid loading incompatible syntax highlighting xml files in older Kate Part versions. Example:

<language name="C++" kateversion="5.0" [other attributes omitted]>

With the new default styles, the Default Styles tab looks as follows:
Default Styles in KF5

 

In comparison, the KDE 4.x version looks like this:
Default Styles in KDE 4

 

The new default style colors are not fixed yet, so improvements and additional color themes we can ship with Kate Part by default are a welcome addition!

A Note at 3rd Party Developers

There are other implementations (such as in Qt Creator or for Haskell). If you developers read this, we encourage you to add these default styles as well once Kate Part 5 is released (stable). Otherwise, the new syntax highlighting files may not be compatible.

Jump to Next/Prev Modified Line

In KDE SC 4.8, Kate was extended by the line modification indicators. These indicators show you what lines currently contain unsaved data, but also lines that were once changed but now are saved to disk:

Modified Lines

With Kate in KDE 4.13, we have two new actions in the Edit menu:

  • Move to Previous Modified Line
  • Move to Next Modified Line

In the screenshot above, moving to the next modified line does nothing, since we are already at the very end of the document. Moving to the previous modified line first goes to line 4, then to line 2, and finally to line 1. By default, no shortcuts are assigned, so if you you want to use this, it makes a lot of sense to configure shortcuts.

Modified and saved lines are treated equally, so maybe we should rather call it “touched” lines, since all lines that were touched by the user at some point in the edit history are taken into account.

The rationale behind these two actions is to allow fast navigation in the text that you actually work on. Jumping over hundreds of untouched lines is quite handy.

Hope this is useful :-)

Lumen – A Code-Completion Plugin for the D Programming Language

I am the original author of the Lumen KTextEditor plugin and I am happy to announce, I just committed it to the Kate repository for KDE 4.13!

Lumen is just the name for a plugin providing code-completion for the D programming language in KTextEditor/Kate and KDevelop. But Lumen is just a connection between the editor and the D Completion Daemon (a server providing all the information) called  DCD. The plugin currently supports all major features of the completion server: feeding the server with import files, displaying documentation and several types of completion:

Imports:

example of lumen (imports)

Basic Completion:

example of lumen (code completion)

Completion (overloaded Function):

example of lumen (code completion)

Calltips:

example of lumen (calltips)

 

To make Lumen work you have to install DCD, unfortunately no Linux distribution has DCD packaged so far. Luckily the D community provides a remedy.

For all Debian/apt based distributions like Ubuntu and Debian of course, there is the d-apt, simply follow the instructions on how to setup the apt-repository and install DCD via apt.  For Archlinux exists an AUR Package. Everyone else has to setup DCD manually, but it’s really not hard, simply follow these instructions.

After installing DCD edit ~/.config/dcd/dcd.conf (create if it does not exist already) and add a path to your D include/import files (phobos), for me this is /usr/include/dlang/dmd (on ArchLinux), for other installations this would most likely be /usr/include/d. Furthermore Lumen will try to read a .lumenconfig in every parent folder of the currently opened D source file and add every line in this file as include path to the DCD server. Add all dependencies of your current project to this file.

Now start the completion server with dcd-server, enable the Lumen plugin in your settings and you will have code completion for the D programming language in your favorite editor!