source formatting: what is supposed to be automatic now?

[Andreas Pakulat]

On 27.11.11 18:59:36, Milian Wolff wrote:
> On Saturday 26 November 2011 16:06:09 David Nolden wrote:
> > 2011/11/26 Milian Wolff <mail at milianw.de>:
> > > On Saturday 26 November 2011 15:40:56 David Nolden wrote:
> > >> 2011/11/26 Milian Wolff <mail at milianw.de>:
> > >> > Hey all, esp. David.
> > >> > 
> > >> > I saw all these commits recently regarding source formatting, and
> > >> > wonder
> > >> > what is supposed to be improved now? I thought that the settings
> > >> > between
> > >> > editor and formatter are now synchronized somehow?
> > >> > 
> > >> > But when I open e.g. sourceformattercontroller.h and override a method
> > >> > in
> > >> > the class, just for the fun of it, like e.g. this one:
> > >> > 
> > >> > "virtual QAction* action (const QDomElement& element) const;"
> > >> > 
> > >> > I get it indented by four spaces, even though the rest uses two tabs.
> > >> > 
> > >> > Same if I e.g. implement a method, I alwasy get indentation by four
> > >> > spaces,
> > >> > even in files that only use two spaces.
> > >> > 
> > >> > Is this because I use astyle? Is all this not implemented there?
> > >> 
> > >> You get the indentation which you have configured in your
> > >> source-formatter. If you use astyle, then you get the indentation
> > >> which you have configured in astyle.
> > > 
> > > Should it not be vice-versa? The editor knows more specific settings for a
> > > given file, and imo the formatter should be configured accordingly?
> > 
> > The editor knows only the indentation-depth, which is 0.1% of the
> > formatting configuration, therefore the formatter knows much more, and
> > the editor is what should be adapted accordingly. Also the
> > formatting-script can work independently of kate or kdevelop (it just
> > needs uncrustify and the "kdev_format_sources.sh"), thus it is a much
> > cleaner solution than distributing .kateconfig and modelines all
> > around. For example, it could easily be integrated into a commit-hook.
> 
> The indentation depth and kind of indentation (tabs vs spaces) is the most 
> important aspect of formatting imo. And people that use astyle have a big 
> problem now, see e.g.:
> 
> [17:08:08]  <tim> hi, running kdevelop, built from today's master branch, it 
> seems that it is using spaces for indenting, although it is configured to use 
> tabs
> [17:09:00] <tim> i am using a kateconfig file, but that doesn't override the 
> indentaion mode (tab-width 4; indent-width 4; replace-trailing-space-save on; 
> eol unix)
> [17:09:04] <tim> is this a known issue?
> [18:32] <milian> tim: kind of
> [18:32] <milian> see kdevelop settings -> formatter
> [18:32] <milian> it's (imo) a mess currently in master
> [18:32] <milian> we really need to improve that
> [18:35] <tim> milian: i see. will revert to the version that i've compiled a 
> few weeks ago
> 
> Right now it's simply impossible to work on a inhomogenously-formatted project 
> with KDevelop, since the most essential formatting (see above) will be wrong.
> 
> People will look for such indentation settings in the editor, which is what 
> they are used to.
> 
> I see how your approach is cool and will work well if all people use 
> uncrustify and projects all come with such a formatting script. But right now, 
> KDevelop simply looks broken for people that still use astyle.
> 
> I think, the new behavior, i.e. changing the editor settings, should only be 
> enabled, if the user uses uncrustify and a formatting script is found. 
> Meaning: For AStyle users, KDevelop should work like before.

As someone who works on a completely 'misformatted' codebase on a daily
base I very much agree with that. Breaking existing working behaviour
for a non-negligible userbase is a no-go, even if it improves things for
a different part of the userbase. But thats what master is for, identify
such things and improve on that.

Andreas