Author Topic: SlickEdit discussion on Reddit  (Read 882 times)

rowbearto

  • Senior Community Member
  • Posts: 1349
  • Hero Points: 101
SlickEdit discussion on Reddit
« on: August 02, 2018, 10:58:20 pm »
I gave a plug for SlickEdit on reddit, and got a question back, see:

https://www.reddit.com/r/cpp/comments/93h8zj/is_it_worth_getting_clion/e3hzg3r/?context=3

Quote
how far behind the current C++17 standards is slickedit?

And does it support CMake?

I'll answer, but perhaps others can too. Especially about C++17 support, which I don't know about.
« Last Edit: August 02, 2018, 11:04:01 pm by rowbearto »

Dan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2289
  • Hero Points: 128
Re: SlickEdit discussion on Reddit
« Reply #1 on: August 21, 2018, 01:13:16 pm »
Thanks for jumping in Rowbearto.  ++heroPoints;

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2648
  • Hero Points: 409
Re: SlickEdit discussion on Reddit
« Reply #2 on: August 21, 2018, 05:31:03 pm »
With respect to C++17 features.  There isn't much in C++17 that has a major impact on our parsing and context tagging.  You could use SlickEdit 2017 (v22) with C++17 code without running into too many problems.  Areas we could do work in the future include:

1) template <auto> -- may require a parsing tweak, template argument type deduction in this case will be difficult, but that kind of falls in the zone of things you wouldn't expect any tool to handle except for your compiler.

2) Class template argument deduction -- nothing special here for parsing, however the actual argument type deduction is difficult, and again, not something you would expect to be handled on the fly by anything except your compiler (and IDE's strongly tied to one compiler, maybe).

3) Constexpr if -- will require a parsing tweak.  I will try to get this in for SlickEdit 2018.

4) Selection statements with initializer -- already handled

5) Constexpr lambdas -- will require a parser tweak.  I will try to get this in for SlickEdit 2018.

6) Inline variables -- already works, but could use some fine-tuning.

7) Structured bindings -- this will be a pain, but we have done this for other langauges (for example, Rust).

rowbearto

  • Senior Community Member
  • Posts: 1349
  • Hero Points: 101
Re: SlickEdit discussion on Reddit
« Reply #3 on: August 21, 2018, 05:57:05 pm »
For cases where "you wouldn't expect any tool to handle except for your compiler", I see other editors/IDEs are relying on clang compiler. For example, there is the "rtags" client/server that allows editors/IDEs to interact with an index of the code based on clang: https://github.com/Andersbakken/rtags#support-for-other-editors

I had an internal debate in my company about this with someone who uses clang with VIM. I argued that I liked SlickEdit because it could index his project of 8500 files in 35 seconds, while his clang indexing took him over 15 minutes. Probably because clang does all preprocessing and a fuller compiling than what SlickEdit does. I think SlickEdit will cover majority of cases for cross-reference search, auto-list members, etc. But it would be nice to have an alternative in SlickEdit to use one of these clang based tools if we wanted super accuracy. There would be a big penalty in indexing time, but it would be nice to have the option to do this if I wanted to and was willing to wait all that extra time.

rowbearto

  • Senior Community Member
  • Posts: 1349
  • Hero Points: 101
Re: SlickEdit discussion on Reddit
« Reply #4 on: August 21, 2018, 06:01:12 pm »
Also see this discussion I had on another reddit thread:

https://www.reddit.com/r/cpp/comments/96ba1y/how_to_use_clion_with_makefiles_and_other_project/e42o7ik/?context=2

Someone here is claiming that with QtCreator and clang that:

Quote
Well, I can only reply with my personal anecdata: 10k files (~1.9Gb) project is indexed by QtCreator in 120sec on a single core (files are located on local HFS+). QtCreator does not store the parsed index on disk, memory usage with this project is ~700Mb.

Not sure I can truly believe that a clang based indexer in QtCreator can really index 10k files/1.9Gb in 120 seconds, but if that were true it would be pretty amazing.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4668
  • Hero Points: 375
Re: SlickEdit discussion on Reddit
« Reply #5 on: August 21, 2018, 06:51:32 pm »
As you probably are already aware, using clang tagging like this would have to be an option and not a default. It's still useful and a small number of users would want it. If you don't use clang, it's useless. SlickEdit customers don't want to have to setup includes in SlickEdit (that's a big problem). They just want SlickEdit to figure it out. This is another reasons SlickEdit customers wouldn't want to use clang tagging. If the performance is like you've experienced, most users wouldn't want it due to the extra cost in performance. We've learned that the hard way. Always opt for performance over features. SlickEdit users want speed.

rowbearto

  • Senior Community Member
  • Posts: 1349
  • Hero Points: 101
Re: SlickEdit discussion on Reddit
« Reply #6 on: August 21, 2018, 07:08:25 pm »
Quote
As you probably are already aware, using clang tagging like this would have to be an option and not a default.
I completely agree.

Quote
If you don't use clang, it's useless.
Not sure I fully agree here. We use gcc and not clang, however clang and gcc take identical command line options. So I think it could also work with gcc users. In fact my colleague who uses clang with VIM for indexing uses gcc for the official build.

Quote
SlickEdit customers don't want to have to setup includes in SlickEdit (that's a big problem). They just want SlickEdit to figure it out. This is another reasons SlickEdit customers wouldn't want to use clang tagging.
I think this is getting much easier to tell your IDE what the includes are, as well as the entire compile command line. There is now a tool that can easily setup a "compilation database" JSON file by running your makefile through it. See: https://github.com/nickdiego/compiledb-generator. I agree this is more work that what is done with SE right now, but seems doable. I see that CLion and QtCreator are both able to read these compilation database files. See:

https://blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db/

I also see many of the most recent commits for QtCreator are about using compilation database JSON files.

In fact, even without tagging it could be useful for SlickEdit to be able to understand compilation database files, for example lets say that I want to compile just a single source file inside SlickEdit. This JSON file can give the entire compiler command line for each file.

Quote
If the performance is like you've experienced, most users wouldn't want it due to the extra cost in performance. We've learned that the hard way. Always opt for performance over features. SlickEdit users want speed.
Agree - speed is paramount. If clang was a non-default option, a user could decide on their own to use it or not and make the speed vs accuracy tradeoff. Additionally, that fellow on Reddit says that QtCreator + clang isn't as slow as my colleague measured (with VIM + clang). I don't know what QtCreator is doing that is special, but you guys may want to check that out. If the speed that he measures with QtCreator + clang is really true, it does seem pretty compelling and I am tempted to try it out.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2648
  • Hero Points: 409
Re: SlickEdit discussion on Reddit
« Reply #7 on: August 21, 2018, 08:31:41 pm »
With accuracy and precision comes a certain amount of intolerance.  SlickEdit's parsing and context tagging has a huge tolerance for incomplete code, scattered preprocessing, and other slop.  That certain amount of imprecision, as John Cougar would call it, "close enough for rock 'n' roll" is vital, because most of the time when you are typing code, you are not done with it yet and it isn't syntactically clean.  We can reach out and see things that clang can't see, for example, a class definition in a file you forgot to #include.

I'm not saying we'll never do it, but we are approaching this feature with caution.  It is a lot to develop and maintain and depend on just to have another way to fail in some other case.

guth

  • Community Member
  • Posts: 82
  • Hero Points: 7
Re: SlickEdit discussion on Reddit
« Reply #8 on: August 21, 2018, 09:51:27 pm »
I have been trying to setup YouCompleteMe for GNU Emacs. It is quite hard. You have to download multiple Emacs packages, download ycmd and compile it for Windows in my case and then load the packages via your .emacs file. I have something that is semi-working. For C++ code it needs a so called project file where the include paths are, but once that is in place, ycmd is a separate process using clang to understand the code and is sending completion suggestions to emacs when the emacs mode asks for them. Since the server caches things, the completions are quite fast and as accurate as intellisense in Visual Studio. Good thing with ycmd is that it handles javascript via tern, rust via something else, etc. so it handles a number of languages.

What I like with Slickedit is that most of the tagging just works. No need to fiddle with things. Maybe one has to tag a specific library being used like boost. And the speed. Slickedit is much faster than GNU Emacs, especially on long lines, that one easily can get in debug outputs or in log files.

rowbearto

  • Senior Community Member
  • Posts: 1349
  • Hero Points: 101
Re: SlickEdit discussion on Reddit
« Reply #9 on: August 21, 2018, 10:46:58 pm »
While I have been the one posting about clang indexing working with SlickEdit, I do have to admit that I have no compelling reason to use it. The SlickEdit tagging is accurate enough for me. The occasional errors I see are usually fixed by Dennis relatively quickly (except if no point release for a few months and a hotfix can't fix the bug, which just happened with the :: parsing error - but that issue only occurred for a small part of our code base). I really like the speed, and as Dennis writes it is quite forgiving with incomplete code, which I benefit from all the time! And setting up my project is very easy - no need to worry about include paths, etc. Additionally I don't often need to browse complicated templates that often, which a clang parser may help with, and SlickEdit already handles these quite well. As it seems like it could be a large effort for SlickTeam to implement/support this, delaying it, doing with caution or punting it seems very wise so that more useful features could be implemented.

My point on this thread was mainly to show the types of discussions I've had internally in my company and also on reddit - to bring this to SlickTeam's attention - especially that claim about QtCreator/clang being so fast, as well as bringing up how a compilation database JSON file could be useful in SlickEdit for building a single source file. In my internal company discussions, I repeatedly make the point that I'd rather have SlickEdit tagging a complete 8500 file project in 35 seconds vs 15 minutes(clang with VIM), and get the ease of use of a graphical IDE vs the difficult learning curve of a tool like VIM + clang indexing. I wish SlickEdit had the advertising budget of CLion and was as well known. I tried using CLion as a license was made available at our company and it was unusable with my large project, and very difficult to setup as our project doesn't use cmake (it predates cmake). I wish somehow SlickEdit was as well known as CLion - seems CLion has a large advertising budget and is riding their success with Intellij.
« Last Edit: August 21, 2018, 11:00:10 pm by rowbearto »

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2648
  • Hero Points: 409
Re: SlickEdit discussion on Reddit
« Reply #10 on: August 24, 2018, 08:14:21 pm »
For what it's worth, SlickEdit 2018 beta3 will have full support for the new language features in C++17.

The only exception is template argument deduction, which is really nothing new, we also do not support template function argument deduction yet, and the new C++17 feature relies on that in order to select a constructor to deduce template argument types from.

hs2

  • Senior Community Member
  • Posts: 2736
  • Hero Points: 288
Re: SlickEdit discussion on Reddit
« Reply #11 on: August 24, 2018, 09:25:32 pm »
Great Dennis :)++