Monthly Archives: November 2012

Common

ID + etags > ID || etags

7 Comments

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!

 

Common, Developers, KDE

Bug Hunting – Please help poor Kate ;)

2 Comments

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 😉

Developers, Users

Default Color Schemas

19 Comments

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 🙂

Developers, Users

Kate Scripting Updates & Zen-like Quick Coding

5 Comments

In KDE >= 4.10, Kate Part’s scripting changed a bit. The changes are already documented in the Kate handbook, but we’ll quickly have a look into it now anyway.

Prior to KDE SC 4.10, scripts in Kate Part always had to contain the “type” in the scripting header, like indentation or command. This was changed to simply using different folders (system wide or in your $HOME kde folder) as follows:

  • indenters are located in share/apps/katepart/script/indentation
  • commands are located in share/apps/katepart/script/commands
  • api is located in share/apps/katepart/script/libraries

Further, the API is not loaded automatically anymore. Instead, we introduced the function require(“file.js”), which takes one argument. For instance, if you want to use the Cursor and Range API, you just write

require("cursor.js");
require("range.js");

In this example, it would even suffice to just write require(“range.js”); since range.js itself contains the line require(“cursor.js”); Kate Part tracks, which files are already included through require, so you don’t have to worry about include guards like in C/C++.

Now as we are able to just load the libraries that we really need, we can add as many libraries as wanted. For instance, the author of zen-coding wrote a thin wrapper to make all the zen-coding goodies available to Kate Part. It’s included in the emmet subfolder in the script/libraries folder. So if you need this stuff, you just write require(“emmet/desired-file.js”);

It’s a bit unfortunate that we still break how the scripting works from time to time, but it’s better to fix and improve the scripting instead of living with limited capabilities. So if you have own scripts, it’s the best time to contribute them to Kate!

Generic Quick Coding Features

Further, we have some new command line script called quickcoding.js that already uses the zen-coding idea: If you for instance write

 c#n:Test#p:Parent

and press Ctrl+Alt+# in C++ files (the Mode must be C++!), it will automatically expand to

/**
 * Class Test
 */
class Test : public Parent
{
  public:
    /**
     * Constructor of Test
     */
    Test ();

    /**
     * Destructor of Test
     */
    ~Test ();
};

So how does it work? Since the file mode is C++, the quick coding command will read files from katepart/script/files/quickcoding/cpp/. The first character of this cryptic string is ‘c’, which tells the quick coding command to look into c.template. This template now expands according to the specified arguments: n:Test sets the class name to Test, and the optional p:Parent derives Test from Parent.

This is just a proof of concept, and you can do the same with Text Snippts in Kate. But still, this is another way adding support for quick coding for arbitrary languges, and the implementation is completely in JavaScript, so it is rather easy to extend and customize it to your needs. We’ll probably extend/change this feature a bit more over time, let’s see 🙂 It’s also not yet documented in the Kate Handbook. We’ll probably add ‘official’ documentation for this in later Kate releases. Happy coding!