Source-formatter

Andreas Pakulat apaku at gmx.de
Sun Jan 10 23:40:02 UTC 2010


On 10.01.10 23:07:30, David Nolden wrote:
> 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?

IIRC thats not whats needed from the plugin. The problem is that the
"language name" is only available once its loaded. The mimetype is
indeed stored in the .desktop file and can be acessed that way.

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

I'm mostly unclear about what kind of widgets you want to place where.
So really a .ui file is enough I think.

Andreas

-- 
You are deeply attached to your friends and acquaintances.




More information about the KDevelop-devel mailing list