decade to improve the IDE we all love most.
mostly impressed by the fluent editor. It was a joy working with that, the code
just streamed out of my fingers. I did not have to think if there is already a
closing brace, I just typed ')' and it always worked as expected. Unfortunately,
over time the editor experience degraded, for example the following bugs:
* QTCREATORBUG-18872
* QTCREATORBUG-21767
does not work anymore for the old-style connects (QTCREATORBUG-20737), which is
a pain maintaining old code bases, but I _could_ live with it.
* QTCREATORBUG-20840
It should not get in my way. Slow code completions, missing navigation, missing
online help really slow me down and are therefore frustrating.
are enough open issues that could be worked on.
that need to be polished. And I really hope to still use Creator in 10 years,
with the same joy I started with.
Von: "Michael Jackson" <mike.jack...@bluequartz.net>
An: "NIkolai Marchenko" <enmarantis...@gmail.com>, qt-creator <qt-creator@qt-project.org>
Betreff: Re: [Qt-creator] Qt creator + Clang model = major annoyance
On some points I agree, but being on macOS my choices are pretty limited for an IDE. xCode? Uh no. Eclipse? No way. What else is there? QtCreator is pretty much the only choice I have. I am hoping that the QtCreator team can carve out some time in 2019 to look into some of the speed issues with the clang backend.
Frankly my issue with the old parser was _because_ of boost. The original code model would _never_ want to parse our use of boost which made code completions pretty non-existent in our boost heavy code. When the CCM successfully parses the file the complete is spot on, it just takes forever to parse the code. One thing that I have noticed is that if I turn off all the clang-tidy and clazy checks then the speed on first opening is pretty decent (I’m on a 2012 Mac Pro with dual Xeon so not the fastest CPUs in the world). If I turn on the clang-tidy checks that I want then the time to get even the function list is abysmal. I would think a 2 stage parse of the file might work better with 2 threads: 1 for the initial parser and one for the clang-tidy checks. Waiting 30 seconds (or sometimes never) for a function list to appear seems like a deficiency in my mind.
Again, I really appreciate how far QtCreator has come from the “old days” in the 2.x versions. I have used it through the 1.5 years of “dark ages” where debugging on macOS was basically non-existent due to LLDB being so immature. QtCreator works way better with our CMake heavy projects and all of the external libraries that we used. I think it just needs some polish on the CCM parsing and reaction times put into it in 2019.
--
Michael Jackson | Owner, President
BlueQuartz Software
[e] mike.jack...@bluequartz.net
On 1/4/19, 8:20 PM, "Qt-creator on behalf of NIkolai Marchenko" <qt-creator-boun...@qt-project.org on behalf of enmarantis...@gmail.com> wrote:
Qt creator is rapidly becoming a source of major annoyance ever since clang code model was introduced.
It's slow, sometimes taking 30+ seconds to react to F2
What's worse, it reacts to it once you gave up and navigated somewhere manually and makes you suddenly type stuff in plces you won't expect.
It's buggy, fails on boost and fails to produce a highlight on everything that depends on it
It's too easy to break, A single symbol it doesn't detect breaks highlighting and hint for the whole file chain, whether stuff later down the line requires that symbol or not.
While I understand the desire to stop reimplementing the wheel with code parser, the Clang Code Model made Qt Creator strictly worse for any complex project to the point I catch myself wanting to use something else on a regular basis. This wasn't the case ever before CCM was introduced.
_______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator
_______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator
