I wanted something in between an IDE and a text editor that could properly parse and understand C++11. I didn't see anything out there that was lightweight and didn't want to take over my entire build system - yet could still parse my code. So I wrote SLED.
The underlying code is designed to be cross platform, but I decided to focus on windows first. Linux has been frequently requested though so I'll likely focus on that next.
I'm in the office so I wont download the beta now, but I think you should add more info on the website about the project (features, platforms supported etc)
What do you mean by "understand C++"?
Does it offer features similar to Intellisense/Visual Assist?
It offers proper auto-complete as well as fast navigation to a function/symbols definition. It can also do a better job at syntax highlighting than regex based highlighters. In the future I'm hoping to add support for intelligent refactoring as well.
One of the problems with having a non-IDE try to parse your code is it doesn't know how its supposed to be built. I put a lot of effort to "guess" your include directories so that libclang could do a half decent job at figuring out the code.
When that fails it tries to make as much sense as possible with an incomplete syntax tree - this part is still very much a work in progress.
1. Have wrapper scripts like sledgcc and sledg++ that keep track of compiler flags passed into them. This way users can just change the compiler used in their build scripts and you will be good to go.
The problem with tools which try to understand the code themselves is that there is a mismatch between what is build by for example a Makefile and what the editor sees.
We are building embedded software using a huge pile of Makefiles and using cross compilers using a lot of product dependent #defines. What is required for us is: find declaration/implementation, find usages of function, find applicable defines, have no false positives for functions which are behind compile options and are #ifdeffed out.
The only IDE which works correctly is eclipse CDT. I think it works by scanning the make processes' output for defines. Are there other good tools which work ok for my scenario ?
indeed. I had a popular app that worked on 5 platforms at the time and it killed me to maintain all of them. This was back in 2000. The tools now help, but still very hard.
I like the concept, would definitely try out again when it's a bit further along. Main things from a quick look:
- Today's monitors have plenty of horizontal space but a shortage of vertical space; the context window needs to be alongside, rather than under, the code window.
- Ctrl-C/X without a selection should copy/cut the current line.
- Autocomplete doesn't seem to work, e.g. type 'st' for the beginning of the 'static' keyword and nothing happens - the underlying mechanism is there and working, because manually triggered completion with ctrl-space does work.
As the alternate opinion, I like the context editor underneath - I always vertically split (even on widescreen), as I can't scan horizontally in that respect.
Make it optional and provide both - always the answer ;)
Also - thanks for writing useful lightweight Windows development software - there's a serious shortage at the moment as most tools (outside Microsoft) have switched to Linux/OSX.
What's it developed in? C++ and Qt? I found it pretty fast, but it was buggy (and for some reason jumped to the same file/line number) on the goto definition selection. Maybe indexing wasn't complete. But it's really snappy!
C++ and win32 (with a light abstraction layer above it). Qt tends to be very heavy weight and I wanted to control as much as possible so I could get near instant boot times.
A few other library dependencies:
- libclang for heavy duty parsing (I also have a "quick" parser that handles simple cases in real time).
- rapidxml for the config files
- boost for Boyer Moore on the string search (but I'm trying to move away from boost eventually).
How do you find using libclang for parsing (and I assume for indexing the source code) -- at one point I was considering writing a C only text-editor that understood the code using libclang for parsing, but was worried that there would be too many corner cases for it to be useful. (Would be cool if you can write up some blog post regarding your experience with it).
Also will sled work for browsing an entirely C codebase (without any C++)?
It should work with C code, right now it will parse it as C++ but that can easily be fixed in the future. The 20th of this month will be the 1 year mark of when I started writing it. Creating an editor isn't for the faint of heart.
I'll consider a writeup for libclang. The documentation isn't very good in my opinion and I'm still not convinced I'm using it right even now.
First and most important: Great project! Writing an editor must be a whole lot of work! Especially when source code analysis is included. You said that you're using clang there. I've also been working with clang (for more than two years by now) and I've got to say that it's a great tool when it comes down to source code analysis. It's a little hard to get into, but it's totally worth the effort - especially when templates are involved. You wouldn't wanna analyze such code on your own ;)
So I think you don't regret using clang there, do you?
Now some feedback:
- I really like how your file search and the file tree interact!
- It would be nice to show the definitions of local variables (e.g. inside a function scope). Or even better: Highlight all usages that variable throughout the scope! That would really help keeping track of things.
22 comments
[ 2.2 ms ] story [ 60.7 ms ] threadAny chance of a Linux build?
What do you mean by "understand C++"? Does it offer features similar to Intellisense/Visual Assist?
When that fails it tries to make as much sense as possible with an incomplete syntax tree - this part is still very much a work in progress.
1. Have wrapper scripts like sledgcc and sledg++ that keep track of compiler flags passed into them. This way users can just change the compiler used in their build scripts and you will be good to go.
2. http://clang.llvm.org/docs/JSONCompilationDatabase.html seems to be a good option. Its reasonably easy to get your build system to emit this and a few build systems can even do this out of the box.
- Today's monitors have plenty of horizontal space but a shortage of vertical space; the context window needs to be alongside, rather than under, the code window.
- Ctrl-C/X without a selection should copy/cut the current line.
- Autocomplete doesn't seem to work, e.g. type 'st' for the beginning of the 'static' keyword and nothing happens - the underlying mechanism is there and working, because manually triggered completion with ctrl-space does work.
If you want to know when its more refined click the "Let me know when its ready" button on http://slededit.com
Make it optional and provide both - always the answer ;)
Also - thanks for writing useful lightweight Windows development software - there's a serious shortage at the moment as most tools (outside Microsoft) have switched to Linux/OSX.
A few other library dependencies: - libclang for heavy duty parsing (I also have a "quick" parser that handles simple cases in real time). - rapidxml for the config files - boost for Boyer Moore on the string search (but I'm trying to move away from boost eventually).
Also will sled work for browsing an entirely C codebase (without any C++)?
I'll consider a writeup for libclang. The documentation isn't very good in my opinion and I'm still not convinced I'm using it right even now.
Now some feedback: - I really like how your file search and the file tree interact! - It would be nice to show the definitions of local variables (e.g. inside a function scope). Or even better: Highlight all usages that variable throughout the scope! That would really help keeping track of things.