Posts 

kdelibs will have coding style conventions. In general. this is not a bad idea. Our 45528 slocs in KatePart all use a consistent indent-width of 2 spaces. Changing this does not really make sense – ok, if svn praise -w (sure, we never need svn blame in our code ;) finally works, we can discuss this again.

In other words: How “consistent” will kdelibs get with this new conventions? The interesting part of Zack’s mail is

Text editors and line edits support the so-called triple clicks according to [1]1. The document says

• Triple Click: Select the targeted row. […]

It is unclear whether the “targeted row” includes the trailing linebreak. Kate Part selects the targeted line including the linebreak. You get the following behavior:

• If you move the selected row with the mouse, you usually have the linebreaks right. The same applies for copy/cut & paste. If you are used to it, it really is a nice feature.

While this behavior is pretty straightforward, it is not widely in use. If you look at text edit widgets like in firefox, konqueror, Qt, KWord or OOo you will notice that they do not include the trailing newline character.

The last week was highly productive for Kate Part, as the following bugs were fixed:

• 89042 while pressing “del” key kate crashes (crash, bt)
• 103648 Codefolding Crash – Reproducable
• 118584 scroll position not upgrading (dynamic word wrap)
• 119435 kate crash when a file is saved
• 123315 kwrite/kate crashes randomly after save
• 124102 changing syntax highlighting when code is folded crashes katepart
• 127928 kate crashes deleting a block of text
• 128690 Dynamic word wrap makes text input slow
• 129853 Horizontal scrollbar and view not synced, if dynamic and static word wrap are off
• and some minor issues

That are 6 crash fixes. Kate Part in KDE 3.5.4 will be more stable than ever :) That’s especially cool for KDevelop, Quanta+, Kile – well and Kate.
Special thanks to Andreas Kling for initiating the bug squashing sessions! You are like a blackbox: The input is a bug and your output is the fix ;)

Modes allow the user to override the default configuration for documents of specified mimetypes or file extensions. When the editor loads a document and the mimetype or file extensions match for one of the defined filetypes, KatePart will read the configuration from the mode and apply the modelines defined. If more filetypes match, the one with the highest priority will be used.

To create a filetype, go into the settings dialog available in Kate via Settings > Configure Kate > Open/Save > Modes/Filetypes, then press the New button and fill in the properties. To remove an existing filetype, select it from the dropdown list and press the Delete button. To edit an existing mode, select it from the dropdown list.

Kate allows you to specify local document variables by setting the corresponding modelines. The hidden file .kateconfig provides exactly the same functionality, but for all files in the directory.

Enable the Feature

To use a .kateconfig file you first have to enable the feature by invoking Settings > Configure Kate. In the config page Open/Save you can find the option Search depth for config file, which defaults to Do not use a config file. Change the value to an appropriate number,

Kate Part’s modelines – also called Kate document variables – are Kate Part’s implementation of document variables, similar to Emacs and vim modelines.

Document variables can be used to set Kate settings local to a file. This is for example for using another indenter than the one defined in the GUI settings. Or assume you work on two projects, the first indents with spaces and the second with tabs, then you can simply add a modeline that contains the specific document variables that set the specific indentation properties.

Note: Please refer to the Kate Handbook for the most recent version of how to write syntax highlighting files.

Hint: If you want to write a syntax highlighting file, the XML Completion plugin might be of great help.

This section is an overview of the Highlight Definition XML format in KDE4. Based on a small example it will describe the main components and their meaning and usage. The next section will go into detail with the highlight detection rules.

Introduction

First at all, why writing plugins for an editor ? Good question, and I hope I have a good answer: Because we want Kate to be small and all extended features not all users need should go into plugins (like CVS suppport, project managment, coffee cooking ;) Therefore Kate provides a quite full-featured plugin interface and interfaces to all important stuff in the Kate application (the documents, views, windows, sidebar …).