KDevelop 5.0.0 release
kdevelop.org
kdevelop.org
Is there such plugin for ST2, perhaps for VSC?
Note: You'll find yourself renaming variables just to get a different color :)
Thats sounds like my nightmare! ;)
I'm very easily distracted by too much coloring, so this just doesn't work for me. If I want to see the usage of one variable I just highlight the usage of this one variable.
I didn't wanted to imply, that I'm thinking this can't be configured in KDevelop.
I've been a regular user of KDevelop for quite a while now. It's simply the best tool for reading existing code, with the variable coloring and powerful code navigation.
It doesn't have that many features that would be useful for writing code (refactoring other than renaming, auto private pointers, maybe helpers for Qt properties), but I'm glad they moved to Clang as the C++ parser. Can't way till it gets to Arch repos.
CMake Error at CMakeLists.txt:22 (find_package):
Could not find a configuration file for package "KDevPlatform" that is
compatible with requested version "4.90.91".
The following configuration files were considered but not accepted:
/usr/lib64/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3
/usr/lib/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3
/lib64/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3
/lib/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3Get kdevplatform from: git://anongit.kde.org/kdevplatform
Install kdevplatform, kdevelop, kdev-rust, etc. into the same install prefix (-DCMAKE_INSTALL_PREFIX=/foo) and you should be fine.
Also have a look at: https://community.kde.org/KDevelop/HowToCompile_v5#3._Run_KD... for setting up the env before running KDevelop.
This exact topic notoriously came up last year where emacs wanted to use exported gcc datastructures to highlight code. This proposal was disallowed by rms sticking so dogmatically to his core values that one GNU project ended up not being able to interact with another, for fear of proprietary vendors doing so.
While I fully understand the technical background to what exporting such data would enable those acting in bad faith to the letter of the license, whats happened here is that 1) emacs users didn't get better highlighting 2) kdevelop never had a chance to even consider gcc as a result and 3) gcc is now failing to compete with another compiler that it really needs to.
What's better, a dead but libre compiler that doesn't interop, or one that has a degree of compromise while still having an effective license that risks proprietary vendors "freeloading" on some good work?
gcc should be fighting hard to continue to provide features competitive to clang while remaining true to it's values, but instead it has opted out of this for hypothetical purity (exporting the data in question is within the license terms and does not require changes in gcc itself, it can be implemented as a plugin, rms just doesn't like it and discourages loudly its implementation as it simply makes it easier for proprietary tools to use it. The situation is quite similar to dynamic linking).
Yes, that is not the most beautiful moment in the libre software movement. I'm pretty sad about it.
I'm not sure this is true, is gcc really competing with clang? I personally don't perceive there to be competition.
I'm not clear on the emacs situation though, is emacs unable to call out to clang for metadata because of the license?
Regardless, correctly parsing c++ is just about the toughest problem there is when it comes to parsing programming languages. Besides clang, gcc, and the parsers in open source projects like qt creator, kdevelop (these two used to be related iirc, but now both are clang i believe), and eclipse cdt, there aren't any free ones. All the rest are closed source. Last I heard microsoft licensed the c/c++ parser they use from a third party. There's value in being able to parse c++ correctly, clang is really exceptional in addressing tool support in this way.
Well, see you later!