Source-formatter

[David Nolden]

Am Sonntag 10 Januar 2010 22:55:24 schrieb Andreas Pakulat:
> On 10.01.10 20:07:55, David Nolden wrote:
> > 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?
> 
> Thats what we had before and it means relying on a certain language
> support being available and loaded. I don't like that. Not to mention
> that for most languages its language == mimetype.
> 
> > Also I think it should be "Language" rather than "mimetype", as
> > "mimetype" is something we don't need to confront the user with.
> 
> Then we should really create a mapping Language -> Mimetype for all
> mimetypes supported (i.e. its supplied by the formatter). Because else
> we'd have "C++, text/python, text/php ..." in one list which looks
> awkward.
Every language has a list of "supported mimetypes" in its configuration file. 
Cannot we just access that information, without loading the language supports?

> > > 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.
> 
> Well, IMHO thats wrong already. A project should ideally use a
> consistent formatting style across the code.
Yes sure, but since kdevelop should also be usable in a non-ideal world, we 
should consider it. ;-)

> > 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 do understand the problem. The thing is that we already now have a
> dialog and a "dialog in a dialog". So we might need to completely
> redesign the configuration interface.
> 
> > 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".
> 
> Can you create a mockup, I'm not quite clear what you mean with dropdown
> or how you imagine this to look like.
I've got enough of hacking for today, maybe tomorrow I will take a look at it.

Greetings, David