Source-formatter

David Nolden zwabel at googlemail.com
Sun Jan 10 19:07:55 UTC 2010


Am Sonntag 10 Januar 2010 19:03:42 schrieb Andreas Pakulat:
> 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.
We could automatically group it by grouping together all mimetypes that are 
supported by the same language-support, and then just call it "C++". Or is 
that the 'completely wrong' thing? Also I think it should be "Language" rather 
than "mimetype", as "mimetype" is something we don't need to confront the user 
with.

> 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.
Fine.

But what we definitely need is per-path formatter settings. Even in KDevelop, 
we have quite different formatting in different components. It's even worse if 
you have multiple projects open in one session, where each project may have 
_completely_ different formatting.

I guess we should by default have per-session settings, and then allow to 
selectively assign other styles to specific paths. Have you thought about that 
already?

I guess the simplest way would be adding a "Path" dropdown under "Mimetype 
aka. Language", where you have a little "+" and "-" button to add new paths, 
and the default path would be "Global".

Greetings, David




More information about the KDevelop-devel mailing list