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

[David Nolden]

2011/11/28 Andreas Pakulat <apaku at gmx.de>:
> 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.

Initially I used universalindentgui, but I started using the
plain-text configuration of uncrustify for the fine-tuning. You don't
really need a preview when the documentation contains an example (or
at least a good description) for most options.

Btw. the general-purpose script we ship does not rely on uncrustify at
all. All it does is calling _another_ custom-script depending on the
path of the file to format, eg. "kdevpatform/language -> Use script X,
everything else: Use script Y".

The second-order formatting-script just happens to be uncrustify for
us, since our (shortened) format_source file is:
# 2-space indentation
language/*.h language/*.cpp : uncrustify -l CPP -f $TMPFILE -c
format.config.uncrustify.2_spaces -o $TMPFILE

# Default: 4-space indentation
* : uncrustify -l CPP -f $TMPFILE -c format.config.uncrustify.4_spaces
-o $TMPFILE