Not having Intellisense can be a good thing, too. It made me realize that if I can never remember my own API, it can be a sign it is not designed well.

It's less that I can't remember the API so much as I strive for utmost readability, leading to descriptive struct member names like ignore_all_persons.  Imagine how much time it saves when Intellisense figures out, nine times out of ten, exactly which variable I want after typing only one character (and sometimes not even that!).  Then just press Tab to accept.  It's a tremendous time-saver.  I could survive without it, but code readability would likely suffer for it, as I would be too tempted to abbreviate all my variable and function names.

Well there are some IDE's that have some of the VC properties:

https://en.wikipedia.org/wiki/Code%3A%3ABlocks
https://en.wikipedia.org/wiki/Eclipse_%28software%29
https://en.wikipedia.org/wiki/Qt_Creator

I found Eclipse slow (java based) although some of my colleagues praise it so much its religous, Codeblocks very fast (runs on the OpenPandora) and complete (but not the stable release, that one is 2 years old, you really want the rc1 from a month ago). And Not sure what happened to Qt Creator, it seems like gone, but was very good a few years ago.

I am curious about http://anjuta.org/ so I'm going to give it a spin.
Never tried this one, but it looks also like something you would want to try:
https://www.kdevelop.org/sites/kdevelop.org/files/photos/Kdevelop_cpp_codetooltip.png

I actually use Notepad++ under wine. Gives me all I need.

I have to say I'm not liking Linux as a development environment.  It has all kinds of neat tools like valgrind (note: minisphere, Cell and SSJ all leak like a sieve ), and of course the package system makes it ridiculously quick and simple to install new stuff, but for everyday code maintenance I'd much rather have Visual Studio, bloat and all.

Doing everything from the terminal and using a text editor to edit source files feels like a massive downgrade after being spoiled by Intellisense.  I know there are IDEs that work on Linux, but... eh.  I think I'll just stick to Windows for primary development.

Use MonoDevelop. It's really good and had decent intellisense last I used it. Plus, apps you do happen to make on it are Mono and therefore cross-platform. I might just restart my Mono Sphere Editor one of these days...

I've been trying to get Sphere Studio to run under Mono, but no such luck.  Before the huge refactoring I did a few months back, it used to throw an exception related to the Weifen Luo controls.  Now it doesn't produce any output at all, and terminates immediately.  Not sure what's causing it and I don't know how to get debugging information out of Mono.

Follow-up: I managed to pin down the Wine lockup.  It locks up whenever it tries to open a document tab.  Wine, like Mono, really seems to hate the Weifen Luo dock panel.

Follow-up: I managed to pin down the Wine lockup.  It locks up whenever it tries to open a document tab.  Wine, like Mono, really seems to hate the Weifen Luo dock panel.

Do the Weifen Luo widgets need .NET >=4.0 or use some obscure, undocumented Win32 |API?

Sphere Studio itself requires .NET 4.5.  It's impossible to backport now since it uses async/await pretty extensively, especially in the debugger code.  But that's not the issue I don't think--everything else seems to work fine under Wine (even things I didn't expect to work, like running Cell and redirecting it's stdout to the IDE), until you go to open a file.  Then it freezes.

I think the problem is that the Weifen Luo controls abuse P/Invoke for calling into native win32 APIs, to support things like interprocess drag-and-drop.  Wine's emulation of the necessary APIs must not be perfect and so it causes deadlocks or something.

The weird thing is that the start page shows up just fine.  It's quite baffling.

Here's a sneak peek at SSJ, the new console debugger that will come with minisphere GDK 3.0.  It has fancy colors and everything!   As a convenience, SSJ will launch minisphere for you, meaning all you have to do to start a fresh debugging session is run ssj <filename>.  This is especially convenient on Linux, which previously required using two terminals, one to run msphere --debug <filename> and the other for the debugger.

Anyway, check out the screenshot, it's looking pretty slick so far I think.

This is especially convenient on Linux, which previously required using two terminals, one to run msphere --debug <filename> and the other for the debugger.

Or you could just run minisphere with a `&` after it, to not make it blocking

I did find that out, although in my attempts at that the two programs would fight over the same terminal, unless of course you redirect the engine's stdout elsewhere (which is exactly what SSJ does).  In any case this matches how GDB and similar debuggers work, where you pass the program to be debugged as an argument to the debugger.

Basically, in Windows if you do start whatever, it opens a new terminal (console) for the program, I couldn't find a way to do the same in Linux.

Traditionally, you would explicitly start another terminal (usually `xterm`, which a lot of distros symlink to be their DE's terminal rather than the real xterm), which works similarly to `start` in Windows. If you pass an argument, that is executed by the terminal, which will exit once that command returns.

# You can run 2 things like this:
$ xterm -title "This is a terminal1" -r -selbg blue -e "/script/or/program/run"  &
$ xterm -title "This is a terminal2" -e "vi" &
# The wait statement waits for all the child processes...
$ wait
# now do some cleanup...
echo "cleaning up"...

SSJ commands implemented so far (names subject to change as development progresses):

"go" - Resumes execution.
"step" - Step over, same as "next" in GDB
"in" - Step in
"out" - Step out
"trace" - Prints a numbered stack trace, 0 is the function currently executing, counts up from there
"var" - Prints local variables for the current function.  Doesn't yet show values.
"eval" - Runs arbitrary JS code in the current context, can also be used to examine variables ("eval someVar")
"quit" - Detaches the debugger and terminates

No breakpoint support yet, and the Step commands don't show any source code for context, but these all work otherwise, so I'm off to a good start.  Oh, and it also reports uncaught exceptions.

It might be nice to have 'continue' as a synonym for 'go' and 'print' for 'eval', since that would match lldb and gdb.

Can you just use the first letter of the command to perform it? That's a really nice feature of most debuggers.