Show HN: Lightweight C++ editor that understands your code(slededit.com)
slededit.com
Show HN: Lightweight C++ editor that understands your code
http://slededit.com/new/
7 comments
Thanks for the feedback I really appreciate it. Everyone uses their editor slightly differently so I'm trying to hear from as many people as possible.
If you want to know when its more refined click the "Let me know when its ready" button on http://slededit.com
If you want to know when its more refined click the "Let me know when its ready" button on http://slededit.com
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.
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.
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.
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.
Could you elaborate a bit on this statement - "SLED is poweful enough to learn how to build your project on its own". How does this work?
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.
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.
I dont know if you have looked at these options -
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.
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.
Another option I'm exploring is using the debug info embedded in the executable. There's lots of good info there.
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 ?
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).
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++)?
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.
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.
any chance of an OS X build will be on your plate in the future?
Its on the radar, but at the moment just one platform is hard enough.
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 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.
Nice. Always happy to see projects like this.
Any chance of a Linux build?
Any chance of a Linux build?
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 was also really excited to try this, but I mostly sit in front of Mac OS X, a Linux, or a BSD, in that order. Bookmarked!
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?
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.
- 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.