source formatting: what is supposed to be automatic now?
Milian Wolff
mail at milianw.de
Sun Nov 27 17:59:36 UTC 2011
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.
Thanks
--
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20111127/2101eb2f/attachment.sig>
More information about the KDevelop-devel
mailing list