Posts 

We have seen how scripting basically works for indentation. It’s also possible to register commandline functions (The command line is bound to F7 by default, or invoke View > Switch to Command Line). We will consider a small example again: sort the selected text.

/ kate-script
  name: unused
  author: foo bar
  license: LGPL
  version: 1
  kate-version: 3.0
  functions: sorter
 /

Read More

My last blog was about the theory of how indentation works by using javascripts. Now we will look at a concrete example: a LISP-style indenter. (LISP indentation is easy, that’s why it’s a good example).
The rules:

• comments starting with ;;; always have indentation 0
• comments starting with ;; should be aligned with the next line
• comments starting with ; should only appear behind code, so they are simply ignored
• every ‘(‘ indents and every ‘)’ unindents

lisp.js looks like this:

Kate Part in KDE4 supports the ECMAScript (JavaScript) language by using kjs. In KDE3 we had several hard-coded indenters in C++, the idea is to let scripts do all the indentation in KDE4.
How does it work? It is similar to vim: You simply create a script in the directory $KDEDIR/share/apps/katepart/jscript. An indentation script has to follow several rules:

1. it must have a valid script header (the first line must include the string kate-script and indentation scripts must have the type: indentation)
2. it must define some variables and functions

Whenever the user types a character, the flow in Kate Part works like this

During the last weeks/days the directory structure of especially kdelibs/kdeui got a major overhaul: in KDE 3 all files of a module were in the same directory which was more or less a mess as you did not know immediately which files belonged to the same category. kdelibs/kdeui in KDE4 has a rather clean structure now (similar to the one in Qt) by using subfolders like

• actions
• dialogs
• widgets
• xmlgui
• several others…

Compare this to KDE3’s kdelibs/kdeui structure. For KDE4 this is a huge benefit, as we have clearly defined groups. We already had lots of discussions in the past about API documentation and this is exactly where the new structure is important: In Qt every class usually belongs to a group (example). Our API documentation tool doxygen of course supports grouping, and now it is even easy to know which class should be in which group. For instance, all classes in the widgets directory should be in the ‘Widgets‘ group, and then maybe even more fine-grained divided into sub-groups.
By the way, we have a policy that every widget in kdelibs has a screenshot to immediately see how it looks like – another nice way to get involved :)
All in all this is really awesome and I’d like to thank all involved developers. Next prey is kdelibs/kdecore? =)

Since KDE 3.5.4 Kate Part supports “smart end“. Right now it behaves like this when pressing “end”:

1. go to last non-space character
2. go to the last character (i.e. hit end twice)

I’m writing this blog to get feedback about what’s the right/expected behaviour. Is it as described above, or should we first go to the very last character, and to the last non-space only when hitting then end-key twice?

Assume you have a .kateconfig file optimized for C++ code that replaces tabs on save. Now you open a Makefile that contains tabs (due to its strict syntax). If you save the Makefile in kate, the tabs then are replaced which results in a corrupted Makefile.

In other words: The .kateconfig file applies to every file. It lacks mimetype/extension support and thus can lead to unwanted behaviours.