Fwd: Re: source formatting: what is supposed to be automatic now?

Andreas Pakulat apaku at gmx.de
Mon Nov 28 15:30:55 UTC 2011

On 28.11.11 15:11:47, Milian Wolff wrote:
> forwarding to kdevelop-devel
> ----------  Forwarded Message  ----------
> Subject: Re: source formatting: what is supposed to be automatic now?
> Date: Monday 28 November 2011, 13:55:20
> From: David Nolden <david.nolden.kdevelop at art-master.de>
> To: Milian Wolff <mail at milianw.de>
> 2011/11/28 Milian Wolff <mail at milianw.de>:
> > Personally though, I find it not very usable yet though. It would be really
> > cool if we could get a proper UI for configuring uncrustify. Otherwise our
> > formatting settings dialog simply makes no sense, as the preview will not 
> work
> > at all. I bet that people using KDevelop will compare the script formatter
> > with the astyle formatter, see that the latter is much easier to configure 
> and
> > use that. Most people won't know uncrustify or know that it is much more
> > powerful than astyle...
> There is a GUI to configure uncrustify, it's an application called
> "universalindentgui". I don't like the idea of creating even more
> hardly maintainable GUI code.
> It's totally fine if people use astyle because it's easier to
> configure. A consistent formatting using uncrustify is mainly
> interesting for larger shared projects which want to enforce
> consistency, like us, and for such projects, I don't see a problem in
> configuring uncrustify _once_ (for example using universalindentgui)
> and then distributing the configuration as part of the source code.
> You have the option: Either you use the simple built-in astyle which
> is easy to set-up but not shareable, or you use the powerful
> custom-script based formatting which is more difficult to configure
> initially, but then can be arbitrarily powerful and easily shared.

I agree with David in so far, that for a 'custom script formatter'
tool all configuration thats necessary inside KDevelop is telling it
which script to use for formatting and potentially any commandline
arguments necessary (it would be nice if things like
<SELECTED_TEXT> <CURRENT_FILE> <PROJECT_DIR> etc. could be used in the
commandline invocation).

Configuration of that script, or the tools used by such a custom script
cannot be the purpose of KDevelop.

That being said, if we ship a general-purpose script ourselves that we
know relies on a certain tool it might be cool to make this script a
first-class citizen among the formatters and provide dedicated GUI
configuration for the tools it uses.

And IMHO configuring a formatter without a GUI is plain useless unless
the formatter only supports certain built-in types of formatting. When
being able to define very fine-grained how the source should look I bet
everybody wants instant feedback of how a given option changes the
formatting. Not only to verify the option does what the user expects it
to do, but also to easily see limitations of the tool.


More information about the KDevelop-devel mailing list