Python plugin gets support for Python3

Being vaguely aware that Python3 had some “interesting” differences compared to Python2, I had decided to not think about Python3 for now, but then one of our dear users piped up to say that even building it was broken! That seemed weird, so I started poking around only to find myself falling Alice-like into a Wonderland where strings were not always strings…

Well, I’ve long been interested in i18n and l10n in all their forms, especially as they apply to Indic languages, so I was somewhat aware of the sorts of issues that Unicode can throw up. Luckily, as a KDE developer I’m used to depending on QString handle all the routine grunt work so it was a bit of a rude awakening to discover that, the C API for Python strings takes many forms:

Note only that, but:
  • Ubuntu does not yet have 3.3.
  • The cmake support in KDE before 4.9.4 cannot find the right libraries.
  • The PyKDE4 support for strings was broken-then-fixed.
  • Python3 pickles structures differently than Python2.
Anyway, with some excellent support from Luca Beltrame and Alex Turbov, I’m glad to say that Pate and its plugins should now work with any of Python 2.x, <= 3.2, or 3.3 in the upcoming 4.9.4 and 4.10 releases. Thanks Luca and Alex!

ID + etags > ID || etags

ID files and TAGS files are generated by GNU idutils and etags respectively. They are often used in coding projects to facilitate looking up, for example, the name of a function, and then visiting where it is defined, etc. In large projects, ID files can be hundres of MB in size, and TAGS files several times that. That looking up is obviously nice to have integrated into your favourite editor…

When I started on getting ID file support into Kate, my need was to efficiently navigate source code indexed using an ID file a bit over 100 MB in size. The bad news is that I now have ID files over 300 MB in size, but the good news is even that is not a problem! Not only that, but by combining the ID file with dynamic invocation of etags, I can have all the TAGS functionality I care about without needing to pre-generate a 600 MB TAGS file as well.

It even works reasonably well even when the ID files and the source files are mounted via SSHFS over a WAN link!

But best of all, you can have it too, from today’s Kate 4.10 beta, using a shiny new Python plugin. Here is how…

You may need to restart Kate, but then you should see a new menu bar entry:

Selecting any of them will display a configuration dialog which allows the ID file to be selected:

You are probably thinking “Wow, that’s quite complicated for a file open dialog!”, so let’s go through the features step-by-step…

  • Remember that KDE’s file open dialog (icon on top right) understands environment variables. So if your workspace has a handy environment variable point to its root, getting to an ID file near the root is very fast (I use “$ws” because it is quick to type).
  • The Browse Tokens functionality performs completion on the token, and setting the “Complete Tokens after” prevent the completion kicking in annoyingly before you have finished typing even a first few characters. Values like 3 or 4 work well in many cases.
  • The Transform Filenamessection allows the filenames inside the ID file to be mapped to slightly different filenames in your $ws. That is useful when:
    • The ID file was built somewhere other than your current $ws. That might be another of your workspaces, or possibly an archived workspace for a released build.
    • The ID file was built on your compile server, but you’ve mounted your workspace at a different mountpoint on your laptop (so you have access to the latest version of Kate :-)). Or perhaps you are using Clearcase, and don’t have it on your laptop.
  • Try “What’s This” on the “With this file prefix” to see how you can simply the setting of this value. In the example shown, notice how the first part of the ID filename “/view/myview/vob” is the same as this value? It seems common practice to put the ID file at or near the top of $ws, so including %{idPrefix} helps support this.
    • More important than saving a bit of typing is that if all your workspaces are built using a common recipe, you will never need to touch this value again!
    • The ID file was built somewhere other than your current $ws. That might be another of your workspaces, or possibly an archived workspace for a released build.
  • The Highlight Matches section allows:
    • etags to be run on the matches in the ID file to distinguish the definition(s) of the token from mere declarations and usage with a distinctive icon.
    • Matches in files with the given suffixes will be flagged with another distinctive icon.

Once you’ve chosen a usable ID file, a toolbar will spring into existence at the bottom of your window:

  • As you can see, the Token field allows browsing by token. Selecting a value will cause the table below it to be filled with the matches from the ID file, highlighted using the Settings chosen previously. (They can also be tweaked using the button top right).
  • Click on an entry in the table to open the file and jump to the match. When you do, two entries will also be added to the table on the right which record where you were before the jump, and where you jumped to. That allows you to easily move backwards and forwards though the browsing history.
  • So what is that Filter thingy? Any matches returned from the ID file, can be further filtered using a regular expression. For example, a filter expression of “%{token} =” will find assignments to “malloc_failure” here:
(Note that you have to use Shift-F1 to get to the What’s This since the toolbar is missing the nice little “?” button).
  • Another nice use of the filter is as a poor man’s full text search: ID files will contain tokens including words in strings. So putting a second word of interest in the Filter will return only the matches which contain both words…
  • Finally, in 4.11, auto-completion is enabled (don’t forget to configure it in Kate->Settings->Configure Kate->Editing->Auto-completion)
Inline images 1
I hope you’ll find these useful add ons to the normal experience of using ID files, but feedback is always welcome!

 

Bug Hunting – Please help poor Kate ;)

The Kate/KDevelop sprint in Vienna was a really productive time.

Thanks to Joseph Wenninger for organizing it and the KDE e.V. for the additional funding!

The Kate team was able to really wade through a lot of bugs & wishes and fix/invalidate a lot of them.

After some more days of work, this really is visible in our nice bug chart ;)

Kate, KatePart & KWrite are now down to a bug level as low as years ago ;)

Still, there is a lot to do.

If you have some spare time and Qt/KDE knowledge, please help us to have an even better KDE 4.10 release and look at the remaining bugs.

We have the following ~60 bugs and ~330 wishes still around. They vary from small stuff to “a lot” of work. If you want to help out, just pick the bug you want to work on and assign it ;)

Default Color Schemas

With KDE 4.10, the naming of the color schemas in Kate Part changed. Instead of having “<app name> – Normal” and “<app name> – Printing” we now just have “Normal” and “Printing,” meaning that all applications using Kate Part now share these color schemas. In other words: If you change the Normal schema in KDevelop, you also will see these changes in Kile, Kate, or any other application that embeds Kate Part. If you just want to change the color schema for a single application, create a new color schema and then use this new schema as default!

Besides that, it’s been a looong way, but finally Kate will ship several default color schemas in KDE 4.10:

Normal Color Schema
Solarized (light)
Vim (dark)

The colors are not all perfect, so we hope to improve them over time, so if you always wanted to contribute to Kate, we could need help here :-)