Category Archives: Users

Improving Syntax Highlighting Files

When building the KSyntaxHighlighting framework, the syntax highlighting xml files are compiled into the KSyntaxHighlighting library. In order to do so, we have a small little helper program that generates an index of all xml files. This indexer also validates the xml files against the XML Schema, and performs some more sanity checks.

Review request D10621 tries to extend the indexer even further and suggest optimizations for our highlighting files. For instance, the rule

 <AnyChar context="#stay" String="&space;" attribute="Normal Text" />

should be replaced by the faster rule

 <DetectChar context="#stay" char="&space;" attribute="Normal Text" />

Similarly, the rule

 <RegExpr attribute="Normal" context="conditionNot" String="\bnot\b" lookAhead="true" insensitive="true"/>

should be replaced by the much faster rule

 <WordDetect attribute="Normal" context="conditionNot" String="not" lookAhead="true" insensitive="true"/>

The proposed patch above generates more than 1500 suggestions to improve our highlighting files, so a lot of work. Help would be very much appreciated. So if you would like to contribute to KDE and are looking for simple work to do, then feel free to get started by sending improved highlighting files to us via phabricator.kde.org (click “Code Review” on the left, and then “Create Diff” on the top right – or even better use arc to automatically manage your patches). Oh, and please increase the version number in the xml files whenever you provide a patch 🙂

Fancy Terminal Prompt

By default, the terminal looks as follows on my Linux distribution:

However, if you are working a lot on the terminal, there are a lot of scripts and tricks available in the net that improve the information displayed in the terminal in many ways. For instance, since many many years, I have the following at the end of my ~/.bashrc:

# use a fancy prompt
PS1="\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\W\[\033[00m\]"
PS1="$PS1 \`if [ \$? = 0 ]; then echo -e '\[\033[01;32m\]:-)';"
PS1="$PS1 else echo -e '\[\033[01;31m\]:-(' \$?; fi\`\[\033[00m\]"
PS1="$PS1 \$(__git_ps1 \"(%s)\") \$ "

Once you open a new terminal, then the appearance is as follows:

As you can see, now I have nice colors: The hostname is green, the folder is blue, the return value of the last executed command is a green 🙂 in case of success (exit code = 0), and a red 🙁 in case of errors (exit code != 0). In addition, the last part shows the current git branch (master). Showing the git branch is very useful especially if you are using arc a lot and work with many branches.

I am sure there are many more cool additions to the terminal. If you have some nice additions, please share – maybe also as a new blog?

Tracking KDE Development

A central place to track KDE development is the kde-commits@kde.org mailing list. To this mailing list, all code changes are sent, containing the log message as well as the diff that quickly shows what really changed. In the early days of KDE development, the changes were maintained by the CVS version control system. Later, this was changed to subversion. Nowadays, KDE mostly uses git, but some svn modules are still around.

Since KDE is developed by many contributors, the  kde-commits@kde.org mailing list obviously has high traffic, ranging from ~100 mails up to 400 mails a day (see marc.info for statistics).

Many developers are subscribed to this mailing list. However, due to high traffic and possibly many changes that are unrelated to your pet project, a commit filter was invented, which was available on https://commitfilter.kde.org for a long time. Essentially, this commit filter allowed to easily setup filters in terms of regular expressions, such that you’d only get mails for changes you are interested in. While this was convenient, the commit filter also had its drawbacks: Instead of getting all KDE changes, you missed a lot possibly interesting conversations: Since post-code reviews are often done by others through email conversation directly on the code changes.

Nowadays, the commit filter is not available anymore, mostly for security reasons since it was unmaintained for a long time.

What does that mean? I’m subscribed to kde-commits@kde.org again, getting all changes. In fact, I am enjoying skimming quickly through the changes, even doing a code review here and there.

I recommend every KDE contributor to subscribe to this mailing list, since it is very interesting to see which projects are actively developed and who really contributes to KDE in person. Even better, sometimes there are discussions on this list, helping you to learn things you didn’t know. Of course, nowadays we also have many code reviews on phabricator, but still the commit mailing list is a nice addon to track KDE development.

Syntax Highlighting Checker

The KTextEditor Framework uses the syntax highlighting files provided by the KSyntaxHighlighting Framework since the  KDE Frameworks release 5.28.

The KSyntaxHighlighting Framework implements Kate’s highlighting system and meanwhile is used in quite some applications (e.g. LabPlot, KDE PIM). What is quite nice is that the KSyntaxHighlighting framework is nicely unit tested. And while we do not have tests for all highlighting files, we still provide some quality assurance through a compile time checker.

How does it work? Well – in former times, Kate loaded all highlighting .xml files from disk (through the KTextEditor framework). This lead to a slow startup over time, since there are >250 .xml files that needed a stat system call at startup.

With the KSyntaxHighlighting Framework, all these xml files are compiled into a Qt resource (qrc file), that then is included into the KSyntaxHighlighting library.

In order to create the Qt resource file, we need to iterate over all available xml files anyways. So what happens is that we take this opportunity and also scan the highlighting files for common mistakes.

As of today, we are checking the following:

  1. RegExpr: A warning is raised, if a regular expression has syntax errors.
  2. DetectChars: A warning is raised, if the char=”x” attribute contains more or less than one character, e.g. when char=”xyz”, or char=”\\” (no escaping required), or similar.
  3. Detect2Chars: Same as DetectChars, just for char=”x” and char1=”y”.
  4. Keyword lists: A warning is raised, if a keyword entry contains leading or trailing spaces. Additional trimming just takes time.
  5. Keyword lists: A warning is raised if a keyword list is unused.
  6. Keyword lists: A warning is raised if multiple keyword lists use the same me (=identifier).
  7. Keyword lists: A warning is raised if a non-existing keyword list is used.
  8. Contexts: A warning is raised, if a non-existing context is referenced.
  9. Contexts: A warning is raised, if a context is unused.
  10. Contexts: A warning is raised, if multiple contexts have the same name (identifier clash).
  11. Attributes: A warning is raised, if non-existing itemData is used.
  12. Attributes: A warning is raised, if multiple itemDatas use the same name (identifier clash).
  13. Attributes: A warning is raised, if an itemData is unused.

This list helps us nicely to catch many mistakes at compile time even before running unit tests.

Update (2017-12-17): All above issues are fixed for all highlighting files starting with the KSyntaxHighlighting 5.42 framework, to be released in January 2018.