That's one thing I really miss in Vim when writing C++. I have reasonably good autocompletion with YouCompleteMe and good code indexing by a combination of exuberant-ctags and rtags, but no debugger integration. To me the editing gains outweigh the lack of GDB integration, since I only infrequently have to debug, but when I do I basically just open GDB in a separate terminal window and set it to "layout src". That said, I also get to use rr[1] from time to time and its productivity gains obliterate any downsides to having to type everything in the terminal, especially for debugging memory corruption. Just record your program until it crashes, then run it backwards with a breakpoint set on the corrupt memory address to see where it gets overwritten. Only downside is that it can't support shared memory.

[1] https://github.com/mozilla/rr

> The final requirement for a reasonable IDE experience is to be able to follow a debugging session in the file where the code exists.

Having a cursor follow along in the file is just one part of a visual debugger. Seeing the call stack and being able to move up/down, the ability to see scope variables, the ability to enter console commands are all essential. Lack of these is why I stopped using SublimePdb, instead switching to pudb: https://pypi.python.org/pypi/pudb

I highly recommend it as the lightest weight interactive debugger out there for Python.

I have the same feeling every time I see these types of "turn your editor into an IDE" posts. There are a lot of features of PyCharm I like, but its debugger is definitely the best and most essential for me.

VSCode has integrated debugging for most languages, but as I mentioned upthread, it's hit or miss depending on the language and environment.

I'd be very happy if the console output when you build something on sublime was smarter, and parsed the output to make out the file and line where the error occurred, and clicking on the error would take me there.

It wouldn't do step debugging or breakpoints, but at least for scripting and even simple c programs it would work well.

It can do this now, but you have to specify your own regex for parsing ("file_regex" and "line_regex" settings).

http://sublimetext.info/docs/en/reference/build_systems.html

>I haven't seen one article for turning Atom/ST/Vim/etc into an "IDE" that comes close capability-wise.

Well, then again, I've never seen an IDE that comes close to ST/Vim/etc in their lightness, speed of opening, editing, switching files, and pleasantness of the core editing experience, much less one without a heavy beast of a UI. Or one that you can setup exactly as you want, as heavy or as light as you like, plugin by plugin, without all kinds of crap builtin.

PyCharm has ideavim with zero-latency typing. It's pretty fantastic.

That's because your definition is flawed.

When it's all said and done, all that matters is that you're able to get the work done. Take vim, for example. You can quite often use CLI tools to get the work done due to vim's integration into the surrounding ecosystem, and this includes things such as debuggers.

For a language like C#, you're never going to find as integrated an experience as you will with Visual Studio. It's just not going to happen.

But for everything else, you absolutely can be as productive in something like vim, the workflow is just different.

My definition of what? I literally said there's nothing wrong with taking that approach. I quite purposely did not argue productivity.

My issue is with the acknowledgment by the author that the standard for "IDE" includes debugging capabilities and then goes on to provide a plugin that provides follow-along only via running GDB, which would need to be configured (I assume, since the author does not specify) the normal ways.

If you want to argue UNIX is the IDE I can get behind that definition, but the debugger is absolutely not integrated into Sublime (or Vim or Atom or N++ or ...) in any meaningful way.

That's why I said your definition is flawed.

The point is to get work done, not do it all in a single window. you talked about "capability" as if because someone uses an external debugger you can't debug effectively or very well when using something like vim.

It's a flawed definition of effective.

When you use something like vim, the entire ecosystem is your IDE.

I've edited my OP and hopefully what I'm saying is more clear.

If the entire ecosystem is your IDE, you're not "Turning Sublime Text into a Lightweight Python IDE".

I don't know how else to phrase this to make it clear that I'm not attacking, denigrating, claiming inferior, etc., composite workflows like vim + GDB. But if you get to an article that says XYZ is now your IDE, and it offers a piss-poor debugging experience unless you leave XYZ, then that article is not turning XYZ into an IDE.

It doesn't matter if you're attacking, denigrating, claiming inferior, etc. The point you made is flawed or inaccurate, and that doesn't change because your motivations are clean.

Of course you can done the work. The question is how effectively you will do it and how much time will be wasted on working around ide flaws.