On Sat, Jan 2, 2021 at 2:07 AM David Edmundson
wrote:
>
> It does. I've tried to collect some stats and provide some context on
> the change.
>
> Taking just plasma-workspace, we have a lot of lines over 100
> characters at the moment.
> 3817 lines to be exact. ~3.3% [1]
> We also have 146 lines o
It does. I've tried to collect some stats and provide some context on
the change.
Taking just plasma-workspace, we have a lot of lines over 100
characters at the moment.
3817 lines to be exact. ~3.3% [1]
We also have 146 lines over 160 chars. One is 383 chars long!
When the limit was 100 we had s
On Fri, Jan 1, 2021 at 6:04 PM Kai Uwe Broulik wrote:
>
> Setting it the column width too narrow makes it have the habit of
> pointlessly breaking statements apart a lot.
Is this a counter-argument to something I said?
If you feel that way (I wouldn't) it does not resolve the
contradiction with
Setting it the column width too narrow makes it have the habit of
pointlessly breaking statements apart a lot.
Am 01.01.21 um 17:59 schrieb Roman Gilg:
> 160 chars column limit contradicts Frameworks recommendation of 100
chars.
On Fri, Jan 1, 2021 at 3:01 PM David Edmundson
wrote:
>
> There has been lots of work on this lately, especially by Alexander Lonhau.
>
> Both in the clang-format file and with some custom changes, and some
> changes throughout the code.
>
> If anyone has specific objections please be sure to note
There has been lots of work on this lately, especially by Alexander Lonhau.
Both in the clang-format file and with some custom changes, and some
changes throughout the code.
If anyone has specific objections please be sure to note any specific
concerns ASAP before plasma is updated.
David
In a similar topic I've been pointed to a tool called qmlformat. It's
basically clang-format for QML.
It seems to work quite well. It insists on a very specific code layout :
https://doc.qt.io/qt-5/qml-codingconventions.html
id first, then newly declared properties and so on. This makes the change
Jan Blackwill has bumped this in a recent MR:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/381
It's a bit easier to visualise the changes, but note gitlab isn't showing
all the changes. It still does better than Phabricator did last year which
just fell over completely.
Bumping
On Thu, Nov 14, 2019 at 7:24 PM David Edmundson
wrote:
>
> Thanks for testing and providing the feedback.
>
> What's extremely frustrating is that many of these issues were
> absolutely fine with the version of clang-format that we were
> intending to use for plasma, then due to timing a differen
Thanks for testing and providing the feedback.
What's extremely frustrating is that many of these issues were
absolutely fine with the version of clang-format that we were
intending to use for plasma, then due to timing a different competing
clang-format file was merged into frameworks, and the r
Hi,
I've just ran make clang-format (thanks a lot for that tooling!) over
plasma-workspace and checked my libnotificationmanager code which is
pretty new, was only written a few months ago, and as such should be a
good representation of modern KDE Frameworks-style code. The results
were not v
By the end of tonight there will be a patch in every plasma repo
adding a build target called "clang-format" using the new ECM macros.
Running "make clang-format" or "ninja clang-format" will tidy up all
code in all repos.
I have shipped this target now so that all devs can test the upcoming
chan
12 matches
Mail list logo
