Source-formatter

Andreas Pakulat apaku at gmx.de
Sun Jan 10 21:55:24 UTC 2010


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.

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

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

Andreas

-- 
Your business will go through a period of considerable expansion.




More information about the KDevelop-devel mailing list