[WIP] Define and implement a consistent indentation style

[dannyedel]

Thank you @zakkak for the input at #29 - I'd like to move the whitespace issue here, and I do fully agree its super annoying.

Personally I think in an ideal world, my editor would do this for me. Or at least some kind of "make source-format" script I can call before comitting, or put into a git filter so I never forget to call it - I'm already doing this to prevent new line at eof

Good news: The tool "uncrustify" you mentioned is in fact available in debian so I could use it without any hassle : )

Regarding actual indents: If I'm not too lazy to configure my editor correctly, I prefer it does one tab for every indentation level. No "one tab, two space" in between, theres just zero tab, one tab, two tab. Whatever a "tab" means, I should™ be able to adjust in some kind of display-option in my editor's preference (Showing one tab equal to the width of 4 spaces usually is a good fit for me).

The emacs article you linked was quite nice, and seems to agree with my generic view of things -- tabs for "Next code level" and if two things within the same code level have to align, use spaces behind the tabs. (There should never be a reason for two things in different code levels to align, that will rain chaos and destruction confusion).

If you could help me get started with it, I'd very much like to have some kind of "rules" file so that fixing the layout of the code is one simple command, then run this command once - generating a massive whitespace-changing pull request - and then hook it into pre-commit or my smudge/clean filters.

Not just for this project, but this seems like the kind of thing one wants to keep handy.

[zakkak]

If you ever decide to go emacs, there is this nice plugin that hooks it with uncrustify and indents code accordingly when you save.

I have also sent you e-mail with an example .uncrustify.cfg to start with.

[dannyedel]

Thank you very much, it has arrived and I'm working on trying it out in this branch. (converted this to pullrequest to see commits at the issue). Work in progress now : )

Turns out, you can tell kdevelop to call an external tool if you say "format source" so all hope is not lost.

My only reason for using it in the first place is its source scanner -- it can very often (even with a few c++11 auto variable types) figure out the type of an expression and offer correct autocompletion for functions and guess candidates for the parameters from the function's expected argument types. As a generic text editor I learned vim (insert flamewar here) but learning emacs is on the list aswell. Perfect would be feeding kdevelop's source scanner and autocompleter to one of the better editors... One can dream.

[zakkak]

Indeed configuring vim or emacs to perform proper autocompletion is a major pain

I would label this PR as an enhancement and not a bug though :-)

[dannyedel]

Just an update that I have not forgotten this, but it seems a lot more complicated than I initially thought. Especially long (qt-typical) connect() function calls usually take a lot of characters (bonus points for me trying to use descriptive variable names, making a single function call easily 100-130 characters long, not counting indentation).

Right now I find it easier to read if they are not wrapped around (disclaimer: I have widescreen display) but if I find some time to experiment I'll try a few indentation styles in the hope that I find one that (a) stops producing supersized lines and (b) is at least as good to read as the long-line calls.