Visual Studio Code 1.2 released

I switched from Atom a few weeks ago, and haven't back. I do miss Atom's regex support in Find All, but I use it rarely enough that I can just fire up Atom when I need it.

Enough of the keyboard commands are borrowed from Atom that it makes the switch pretty painless.

Hi. I've been looking for someone that uses vi seriously. I have struggled to use it quickly. Can you give me or do you know of a short screencast of someone using vi at their comfortable speed. I can't understand yet how it can be faster than autocomplete.

The "VimStyle" plugin is probably the best Vi-emulation mode for VS Code right now.

Why do you use vi and not vim?

I run it on a Macbook Pro 15 2015, a Macbook Air 11 2011, and a frankenbox with an i7 from 2013.

On the Air it takes 10 seconds or so to launch. On the others it's less than 5 seconds. Compare to PHPStorm, which is kinda useable in less than 30 seconds, and takes a minute or two to index a relatively small codebase and be fully useable. (Of course, PHPStorm does a lot more than VS Code, but I find that I don't use it anymore anyway; testing startup time just now was the first time I'd opened it in months. I guess I should stop paying for it.)

In fairness, x11 emacs is literally the snappiest thing I have ever used on any platform. It is totally nuts.

On my lowish-end HP laptop (Intel Celeron(R) 3205U @ 1.50GHz, says /proc/cpuinfo), Geany is my IDE of choice for HTML, PHP, and C stuff. It starts instantly, never lags, etc.

Emacs has always been a bit laggier than that (and a few seconds to start). VSCode starts slower than Emacs, but once it's running it feels much snappier--on par with Geany, though I still only use it for C#/F#.

On my Ubuntu netbook that I use for short trips and on Windows, mainly for Rust editing.

The netbook has 4GB with dual core Brazos APU and it is quite fast, to the point that it is maybe the only web based application that I run as desktop application.

Well, of course, the Electron framework, which is essentially a stripped down Chrome browser, consumes more hardware resources than a terminal-based text editor.

On my machine (Core i5-4590, no extra graphics card, 8 GB memory), once it's open (which takes a while), it's nevertheless very fast and definitely not sluggish.

I'm stoked they're going to add tabs. When they first launched code, they said they didn't want tabs. I guess they thought the document explorer thing was the best option. But it totally turned me off from using Code.

What, in particular, about the UI don't you like? Is it just the lack of tabs?

Terminal is already in there and mentioned in the root link. Just press Ctrl+` and it will show up.

Terminal support is in this release ;)

Seconded. Everytime I've tried VSCode I've been very impressed. (More than every time I tried Atom).

It's snappy, has a nice UI and lot of great out of the box features.

I just opened a project in VSCode, closed the VSCode, deleted the project, and now when I try to open VScode the program won't load. Did I break it?

Also, how do I autocomplete using suggestions from other files within the project directory?

Unfortunately it's not on par with actual vim or what you get with Sublime and IntelliJ.

The vscode vim plugin mostly emulates the modality of vim, without support for things like :%s/x/y/ substitutions and other commands.

I'm hoping that with time it will mature and improve. Haven't seen any improvements over the last few months though (I last tried it about 2 or 3 weeks ago).

I've tried three, and VimStyle has been the best by far. The plugin marketplace shows it having a lower number of installs, but that's probably due to it being a bit later to market than the others.

I was just using vs code now with vim bindings and was running into roadblocks.

For example, 23G doesn't go to line 23. d5d doesn't delete 5 lines.

Vim key bindings still have a way to go.

I'm not much of a vim user, but vs code is _amazing_ for programming in Go. I dropped sublime after about 30 seconds of use and have not looked back.

It's pretty poor; expect only the basics of moving. I don't think this is a technical problem though, just a plugin maturity problem.

Yup the only reason I'm currently using Atom over VS Code is because of the VIM bindings, even though pretty much everything else about VSC is better (including feeling more snappy)

Same. Deal breaking for me. Pretty hard to use without ci commands.

That's because Intellisense is not about regexp matching.

Consider how in Emacs there are usually simple packages for a language (say, ruby-mode), and complex ones for live-analysis (say, robe).

There are samples showing how to take a TextMate grammar and wrap it into a VSCode extension. TextMate's system is a bit more complex than Notepad++, but not by much. That will give you the basics at least. (Beyond that you'd need to write a "language service" which can be as easy or as hard as you want to dive into compiler trivia.)

I've heard that Visual Studio "15" Preview (not VS 2015, but the next version in development) already supports TextMate language grammars too, and that it is intended to make it easier to eventually share language services between VS Code and VS "Proper", but other than skimming BUILD Talks on the subject I don't know how far along those efforts are.

In terms of ease of extensibility, I haven't found anything better than Howl (http://howl.io).

Disclosure: I'm one of the contributors.

This needs much improvement also given the lack of backward compatibility in the styles' XML of the current VS 2015, essentially forcibly deprecating studiostyl.es...

Doesn't the Clojure syntax higlighting work for you? I've been using it with a variety of LISPs for a while.

Could you expand on why you don't like to use an auto-formatter? I'm genuinely curious.

I'm pretty addicted to them; they add consistency without me having to think about it (killing off bike-shedding in the process), and in practice it works a bit like a visual semi-linter: if the auto-formatting doesn't produce the expected pattern (and your mind very quickly picks up the pattern subconsciously), it usually means there's a bug in the code somewhere around the area where it goes wrong.

I use kate (KDE Advanced Text Editor) and there's a setting that removes trailing whitespace whenever you save a file. Works awesome.

You get auto-indent and at the same time don't have to worry about leftover whitespace everywhere when you 'git commit'. In fact, after accepting pull requests I'll often just open up the files in kate and doing a trivial edit + save to ensure there's no pointless whitespace.

The IntelliJ family of editors will automatically put the caret at the right indent level wherever you are in the file, but leave the line empty of whitespace unless you actually type something on that line. That makes a lot more sense to me.

F1 then type trim. The first option to pop up should be the trim whitespace command. Hit enter. Or there is an option to trim automatically on save.

They do have a setting to automatically remove whitespace "files.trimTrailingWhitespace": true

Or I don't understand what you are talking about ?

The F1 keys opens up the command palette [1], I'm assuming it's accessible through there.

[1]: https://code.visualstudio.com/Docs/editor/codebasics

There is an F# REPL for VS Code[1], so it's possible at least. Can't say how hard it is though.

[1] http://ionide.io/

They usually release once a month. This is not the Microsoft of yesteryear with 1 monolithic release perfectly tested, and released once every other year.

They're making incremental progress, and releasing often. The software is noticeably better than it was even 2 months ago.

I write C#, JS, PHP, and Python... and I can do development for ALL of those languages in the same IDE. It's kind of great.

Maybe. VSCode's releases are monthly.

So, like never? Also, if it's fast at what it does, what is it to you if it uses v8 and node?

I'm sure if you wait long enough we will come full circle again.

How would that be an advantage over the current platform?

Actually, I've been using it since the beginning and have no interest on file icons - I like it just the way it is, without colored baubles festooning an otherwise monochrome and distraction-free file tree.

(I prefer reading the file extensions anyway, since they stick out on the right hand side)

1606 install of the plugin probably isn't everyone, but I suppose your pull request will be welcome :)

doubtful, seems to me that the whole point is to provide a light weight cross platform editor that supports asp.net core, typescript etc... in order to drive adoption of those technologies.

Merging it with VS would either require making VS cross platform (massive undertaking I would think) or a massive rewrite which would have dubious value to MS.

Better than sublime, not as good as pycharm. I find it good enough.

It seems like I see you commenting on every single article posted about Microsoft here and you always seem to have something negative to say about Microsoft.

What's your point in commenting? Do you really think you're adding to the conversation and deserve upvotes or are you on a mission to let everybody here know that you hate Microsoft and that you don't think anybody should be doing anything with Microsoft?

Honestly - what do you expect to accomplish and what did Microsoft ever do to you?

Did Microsoft kill your pappy? - http://www.hanselman.com/blog/MicrosoftKilledMyPappy.aspx

Microsoft has been doing really good concerning open source and developers recently. ASP.NET Core, .NET Core, VSCode, a free Visual Studio Community, etc. Note that I'm no MS fan, these are just facts. Also, the aim of VSCode is not to replace vim, obviously. How do you put a "web rendered" editor in a terminal anyway? Also, as a vim user, I can say that using vim in a GUI is fine nowadays, Gvim works really well on Windows fyi, has good font rendering, same on OS X (MacVim). Don't limit yourself to the terminal if you're in a GUI environment such as Windows...

You have a very specialized and unique setup. Congratulations on finding something that works for you, but don't pretend that your use case is anywhere near the majority of people using this.

It's not overhead, but a feature that allows for a great variety of plugins and cross-platform compatibility. If you can't see the advantage of that, I feel sorry for you.

It would be nice if the man childs who need to point out "electron bloat" in every thread could go back to arguing about vim vs emacs.

Let me preface the following by saying that a text editor is a use case where an Electron-based desktop app can make good sense.

I recently put some time into experimenting with Electron, writing a simple media gallery app for viewing all the images and videos in a directory (https://gitlab.com/steve-perkins/MediaGallery-electron).

Certain things were easy, due to the fact that it's largely a web app under the covers. Certain things were frustratingly impossible, such as detecting whether a video is supported without adding it to the DOM and attempting to render it. Other things fell somewhere in between. HTML/CSS/JavaScript is a secondary skillset for me, so it felt like I swimming upstream to make a web app format and behave like a desktop app.

My primary skillset is Java, and I haven't yet had a chance to tinker with JavaFX (i.e. Java's answer to Microsoft's WPF and XAML). So I decided to write a JavaFX version of the app for experience (https://gitlab.com/steve-perkins/MediaGallery-javafx).

It was still a pain in the ass to learn a completely new GUI framework. But it was a relief to work with layout managers that actual want to function in a desktop paradigm. It was also nice to have unfettered access to local API's beyond the web-server-focused ones available to Node.js, and to have cleaner integration with the main process and the renderer thread. Interestingly, Java supports far more media types than the Electron browser engine.

Here's the kicker. Not many people know about it, but modern JDK's ship with a "javapackager" tool that bundles up your app into a native executable with a stripped down embedded Java runtime (and even a platform-specific installer). Believe it or not, the standalone installer for my JavaFX-based app is about 25% SMALLER than the installer for my Electron-based version.

Now, I'm not necessarily saying that JavaFX is a panacea for cross-platform desktop development. There really IS no ideal solution for that space, because so few people still care about it these days. However, I will say that Electron seems to make sense only for distributing apps that are basically just web apps, or perhaps have very limited native interaction outside the DOM (i.e. loading and saving plain text files, or spawning external processes). If you need to write a cross-platform desktop app that really IS a desktop app... then I think you're stuck with a C++ framework like Qt or xwWidgets, or perhaps JavaFX.

They do much better work with use of threads though, so it seems much faster than atom to me with no lockups.

How else would you port a typescript/javascript editor to the Desktop? They do state they are working on decoupling the core Monaco editor but where else would you host it to make it faster?

How often do you install extensions? Seems like one of those bothersome things during setup, but I doubt it would be impactful once you have it the way you wish to have it.

Does it take you more than 5 seconds to reload the app though?

Search and Replace in multiple files. That's among the top 10 features that should've been available since release 0.0.1 in any code editor. They're at 1.2 now and still no cigar. Who's the project manager who keeps saying "nah, don't need it"?

Then again, it's a good litmus test. If you find yourself opening your old editor to do something so basic your new editor can't do: what the hell are you doing in your new editor?

I use it daily (running both Visual Studio 2015 and Visual Studio Code). For me, it's a Sublime Text killer.

We have some small node apps, endless python scripts and I routinely deal with configuration files, XML, JSON, even just machine-formatted flat files. It's very good at doing that when I need it to, and being a lightweight IDE when I drop into node or python. Anything that doesn't require me spinning up the full IDE but comes with good editing and search (what I was using Notepad++ and Sublime for in the past) is a win for me.

There are some really nice features in there too, the extension ecosystem is very active and it does what I need it to. Pleasure to use.

The community bookmarks extension launched back when extensions did. It's quite mature at this point and you should check it out if you rely on bookmarks. https://marketplace.visualstudio.com/items?itemName=alefragn...

It is a work in progress. Not perfect but does many things right. If you look through their backlog they seem to be adding features carefully based on user feedback and priority. But there is atleast one extension in the marketplace meanwhile.

It's more of an alternative for people use sublime text or atom, rather than an alternative to visual studio.

I never use bookmarks or code folding. Perhaps people like me are in the majority?

It does with a simple jsconfig.json file: https://code.visualstudio.com/Docs/languages/javascript

Has pretty decent autocomplete, param info, jumps to definitions and references.