Hi Bruno,
OK, if we have an agreement on that, we will merge MR 298.
Thus the .clang-format will be in the root of the trunk and people
can start to use it.
We will have a test phase (2-3 months), so we can probably find
and fix some issues in .clang-format, update documentation.
Also
Thanks Anton, it makes sense to me.
On Mon, 21 Oct 2019 at 21:02, Anton Gladky wrote:
> If we do a one-shot-reformatting - it is also OK. But I would then prefer
> to set the author of this commit, something to "clang-formatter",
> Just to identify, that this particular change was done by this
Hi Bruno,
I think Janek has already answered most of the questions.
> What would be the workflow in general for, let's say, a kdevelop/kate user?
It is supported by most of IDEs, as it is getting to be a standard
tool for industry. The command-line tool will work always though.
> I'm
Thanks for clarification Janek,
Yes, apparently kate and kedevelop5 [1] both have clang plugins.
Might be a bit more involved to get it working on 16.04 (there's kdevelop4)
but it should be doable.
Bruno
[1] https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available
On Mon, 21 Oct
Bruno Chareyre said: (by the date of Mon, 21 Oct 2019 11:57:28 +0200)
> Hi Anton,
> It's not yet all clear to me how it will work.
> What would be the workflow in general for, let's say, a kdevelop/kate user?
> Edit, then "git-clang-format" before commit?
I pushed the script
Dear all,
there are several pre-defined styles in the clang-formatter.
I have recursively run all of them in the current trunk and I controlled,
how many lines were changed (+ lines added, - lines removed)
Style | + | - | Line length
LLVM |
6 matches
Mail list logo
