You're describing VS Code. Now you may not think it's lightweight, but for anyone not toiling away on a turn of the century machine it's plenty fast and has great debugging facilities.

I actually switched to VS Code vs Sublime for most tasks just recently. It has a few quirks (looking at you, files that just close for no reason) and isn't quite as quick, but the language/debugging packages and support are just leagues better.

> ... files that just close for no reason)

Do you mean if you select (preview) a file from the tree browser on the left, the file appears, but if you select another one, it goes away ?

Use this setting/preferrence:

"workbench.editor.enablePreviewFromQuickOpen": false,

Or double click to fully open them.

I only go back to sublime when i have to open really large files. Apart form that, couldn't be more happier with VS Code.

...as a sublime user, I go back to vim when I have to open really large files.

I've never used vscode, but this makes me wonder how small a file has to be for vscode to manipulate it quickly.

I have had better luck with sublime when opening very very long lines (think 56k chars). This comes from a sqldump. Even vim was not up to the task.

My case was also a sqldump, actually. I forget what I eventually did. I think it had to do with hitting Ctrl-C to stop the entire file from loading up front, and only load the page I was looking at.

The link to this SO question was purple when I Googled this just now: http://stackoverflow.com/questions/908575/how-to-edit-multi-...

In retrospect, I do remember also messing around with disabling syntax highlighting and splitting the file up into more manageable chunks that I loaded into separate buffers.

For my purposes, I was trying to delete certain portions of the dump - so vim was the perfect tool to do something like "delete everything from line 850 to the next time this regex is matched", with a minimum of scrolling around and rendering things unnecessarily. iirc, Sublime just locked up and refused to scroll.

I wonder if I could have used Vintage to do what I wanted in Sublime?

vim might very well be if it turns out you had syntax on. I've yet to have vim fail on me as long as I skip the pretty colours for big files. Then again I've had very long lines indeed but can't tell if they were that long.

You wouldn't use VSCode to edit one off files. You'd use VSCode when you want to mount a "project" folder, and then access the files within that.

You "can" open one-off files from the command line. It's just way slower than other methods if you're just doing a quick change, and you'd go mad waiting for the file to open.

"Files that just close": Ironically, VSCode adopted that feature from Sublime, and it works exactly the same. They're "preview" tabs, which you can recognize by the fact that the title is rendered in italics. You can make the tab permanent either by editing the file, or by hitting Cmd-K-E (on macOS, no idea about other OSes).

> files that just close for no reason

I never experienced this, which type of files ?

I actually looked into it a bit more. This may have been the fault of the default "workbench.editor.enablePreviewFromQuickOpen": true, as quick open is literally the only file opening mechanism I use (I assume, if that's cmd+p). Weird default. I turned it to false, maybe that will fix the closing-files issue.

Now if only I can get it to stop automatically closing quotes during comments and ruining my english contractions:

// it' => // it''

Any way around that? :(

This sounds like a bug or bad setting. I'm able to type contractions in comments in Sublime without it auto inserting a closing quote. Perhaps try reverting to default settings for a moment.

"editor.autoClosingBrackets": false

Unfortunately, that also turns off all bracket matching.

Yeah, I saw that, that's no good. I like it 98% of the time :)

Files that close for no reason is caused by preview mode, which can easily be turned off in the settings. Otherwise you need to double click or edit the file for it to remain open.

Once VS Code sorted out some plugins I was missing, plus the live view scrolling. I switched completely. It's updated way more often than Sublime, and I was a paying customer!

I tried Sublime and VS Code with plugins, but I found the autocomplete to be really subpar compared to JetBrains IDEs, which I use day-to-day for work. Any plugins for JavaScript and Python that would improve that situation?

Unfortunately, I doubt you're going to get these same level of autocompletion as IntelliJ et al simply due to the amount of indexing that IDE does.

It's a trade-off, there are times in code, I just don't get autocomplete, especially from other file references... or it starts a few moments after I've opened the file... On the flip side, code never seems to just wig out and freeze for several seconds at a time (after initial open) like most IDEs tend to.

I'll take having to remember what I'm trying to type, look it up etc, and have autocomplete mostly work, vs. my editor wigging out in a large project for a really small change.

Also, absolutely love the integrated terminal and the git integration, though better merge/rebase would be nice.

Yes, definitely have faced that problem with IntelliJ. It eats up memory and consumption grows while the IDE stays open, which it always does for me. Better autocomplete would be the killer feature that would win me over, so fingers crossed it gets better!

Have you tried ternjs (Sublime Package: https://github.com/ternjs/tern_for_sublime)? I use the config file from https://github.com/tststs/atom-ternjs/blob/master/README.md#... as a basis, works quite well.

I'll give it a shot. Thanks for the recommendation!

You got me excited, but VS Code is missing the one feature that prevents us from using it (or Atom, or Brackets): the ability to open, display and edit a file with null bytes in it. Sublime does this wonderfully. VS Code refuses to open the file. Atom pretends the bytes aren't there.

Add a ticket to the github repo? It only takes a second. You could alsp fix it yourself and make a mr if you're able, it's just JavaScript.

Huh, interesting. VS Code does have an "editor. renderControlCharacters" option.

You can have it with Emacs, depending on the language you are using. I have used C/gdb out of the box quite happily and now I use python (elpy) and it works although with some annoying glitches from time to time. Other languages don't work quite well.

> if I can't click on a line number

If clicking isn't a hard requirement, I think there is something to be said for command line debuggers with well done interfaces.

I spend a lot of my time in Python at the moment which doesn't usually require a debugger because of its restricted control flow, but every so often I find myself in need and I always gravitate to PUDB (http://heather.cs.ucdavis.edu/~matloff/pudb.html). And I haven't found it wanting -- yet.

Writing Python, I'll use Ctrl-G to go to a line or Cmd-R for a function then insert the breakpoint via a snippet triggered by pdb<tab>.