Category Archives: Developers

Remove Trailing Spaces

Up to KDE 4.9, Kate Part had support to remove trailing spaces in two ways:

  1. Remove trailing spaces while editing
  2. Remove trailing spaces on save

The reasoning behind removing trailing spaces while editing is that when working on a document, we want to keep our own changes clean of trailing spaces. This way, we can for instance provide patches that are not cluttered with whitespace changes, and we just change lines that we really want to change.

The implementation of this feature unfortunately had quite some regressions that we were able to “fix” over time. For instance, you do not want to remove trailing spaces if the cursor is currently in the trailing spaces area. This alone means we have to kind of remember that we touched this line, and then remove it later. This was always hacky, and in fact, there are still corner cases that did not work.

For KDE 4.10, the both options were merged into just one option Remove trailing spaces with three possible values:

So we only support removing trailing spaces on save from KDE 4.10 on. The implementation is now very clean and based on the line modification system available since KDE 4.8: Thanks to this system we know exactly which lines in the document were changed. So if you choose “Modified Lines” in the configuration, trailing spaces of these modified lines are removed, and other lines remain untouched. If you choose “Entire Document”, then all trailing spaces in the document will be removed. And, needless to say, “Never” implies that trailing spaces are never removed.

For compatibility, the old mode-lines “remove-trailing-space” and “replace-trailing-spaces-save” are still supported, but you’ll get a kWarning() on the console. All these changes are also documented in the Kate handbook (once KDE 4.10 is released). From KDE 4.10 on, you should switch to the modelines

- remove-trailing-spaces none;
– remove-trailing-spaces modified;
– remove-trailing-spaces all;

Hope you like it…

Data Recovery in 4.10

Recently I’ve blogged about the usage of KMessageWidget in the data recovery process in Kate Part. Finally, we decided to stick with KMessageWidget, since it is a standard kdelibs widget, used by a lot of KDE applications. Besides, it is visually appealing and attracts the user’s attention. In KDE SC 4.10, it will look like this:

Now if you recover the data, it may happen that the swap file is broken, e.g. because it was accidently manipulated for whatever reason. Then you get notified like this:

Besides that, we are currently at our Kate/KDevelop meeting in Vienna. Lots of exciting stuff is happening, so expect more in the next days :-)

Project Plugin, Current State

After some days of more hacking on the plugin, there current state is already nice for my daily use.

A simple file like

{
     "name": "Kate"
   , "files": [ { "git": 1 } ]
}

defines already the complete project for the kate.git.

If you open any file with Kate inside your local kate.git clone (and the project plugin from master branch is loaded), Kate will auto-open the project and highlight the file you just opened there in the tree. No need to think about opening some project in the menu, just open the file you want to start working at and start. The project plugin won’t get into your way or require additional steps.

It will allow you nice and fast file switching between your project files in the filesystem tree like structure without any noise of non-git tracked files ;) Still the normal “Documents” view is around like it used to be, if you want to just navigate between currently opened files.

If you modify the project file, the project will auto-refresh itself, still a reload button is needed to trigger e.g. reparsing of git files, if your add/remove files and want a fresh project tree. The auto-reload won’t help there, as is is more or less a nop if the project file content was unchanged.

The “Search and Replace” plugin will integrate nicely and per default will do project wide searches, if any project is currently active (you can switch to other search modes like before in the combobox, just the default is changed, if the project plugin is active). Thanks to Kåre’s nice design of the plugin, this addition was really easy to implement.

Exuberant Ctags integration is work-in-progress. At the moment on project load, a background thread will generate a ctags index (after it has constructed the file tree from git/svn/…) and the auto-completion will use this index for all files associated with your project. An additional toolview, that allows you to search inside the index will be implemented, too. It is a bit like the current ctags plugin, but without any setup or manual indexing ;) For the kate.git, the indexing (in the background) needs less than half second, even for kdelibs frameworks branch it is only 2-3 seconds. On Kate exit the index files (created as temp files in your local temp directory) will vanish again. No index database polluting your checkouts/clones or homes.

Will try to add more features I like for my daily work, if you have any ideas to improve the plugin, just let me know here or on bugs.kde.org ;)