Source-formatter

Andreas Pakulat apaku at gmx.de
Sun Jan 10 18:03:42 UTC 2010


On 10.01.10 15:26:05, David Nolden wrote:
> I've tried the source-formatter after the remake. I think using the mimetype 
> for matching is not overly useful, as it distinguishes between "C Header", 
> "C++ Header", "C Source", and "C++ Source". In our codebase and in many other 
> C++ projects, "C Header", "C++ Header", and "C++ Source" are 
> indistinguishable, so having to select a formatter for each of them is 
> needlessly complicated.
> 
> I think we should change the selection of the source-formatter like this:
> 
> The main selection would be the style-name. For each style:
> - Allow selecting a set of paths
> - For each path, allow selecting a set of wildcards like "*.cpp *.h", which by 
> default should just be "*" to select the exact files where the formatting 
> should be applied.

Completely disagree. The system as it is right now makes perfect sense,
though we might indeed want to group by language instead of mimetype.
Before the rework the sourceformatter relied on language supports to do
this "grouping", which IMHO is completely wrong, so I fell back to
mimetype (which is also whats natively reported by the sourceformatting
apps). Adding some grouping isn't a big deal, but wildcards is
completely wrong. Thats simply not sufficient for identifying the type
of a file. And most formatters only support a limited set of filetypes,
neither of the two versions currently support cmake files.

Also you can already now easily share the same style among different
mimetypes (as opposed to before where the list of styles where depending
on the selected mimetype).

> Ideally, we'd also store the rules in-source, right within the paths, so they 
> can be shared through VCS systems, but that would be for the future.

As with all other settings, we just need to find a proper gui to move
settings from global/session to project and in project from dev-specific
to project-wide (i.e. move from kdeveloprc ->
<project>/.kdev4/<project>.kdev4 -> <project>/<project>.kdev4). Then
there's no further need to store anything inside a file which clutters
the users files.

Andreas

-- 
You'll wish that you had done some of the hard things when they were easier
to do.




More information about the KDevelop-devel mailing list