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
No exceptions. Either everything or nothing
While everything would really be cool, in truth it’s not possible to achieve, is it? We will have exceptions or rather violations, I’m pretty sure
Some developers already start adding katepart modelines to their souce code. For those who don’t know yet: You also can simply use a single .kateconfig file, which is the equivalent to emacs dir config files. You just have to make sure to set the search depth for a .kateconfig file to – let’s say – 3. Do this in
Settings > Configure Kate… > Open/Save
It is not a secret that removing Kate’s project manager in KDE 3.5 was not the right thing to do. It seems a lot of people used it and we got many complaints about this decision. That also shows that it is hard go get feedback about what users are really using. If a feature is done well, noone will ever talk about it. This is paradox, as we thought the project manager was not well integrated (I still think that)
Ok, let’s come to the interesting part: Three developers wrote a new Kate Project Manager Plugin and published an initial release on sourceforge.net and on kde-apps.org. It works quite well already and reading the comments on kde-apps.org gives me the impression that there are more features to come with the next release. — If you are interested maybe you want to join the project…
PS: I have the secret hope the plugin will be ported to KDE4 using Qt’s model/view architecture, so that it has good support for multiple mainwindows
Text editors and line edits support the so-called triple clicks according to . 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.
Question now is: Should we change it for KDE 4 in Kate Part just to be compliant with the others? As Kate Part is an editor component mainly used for programming, my favourite option is to include it, i.e. to keep the current behavior.
(update) I just stumbled over http://bugs.kde.org/show_bug.cgi?id=91041 =)
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