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