It's interesting how people seem to have very different experiences with lag on vscode. I wonder if it's actually much more laggy on some system configurations. What are your running it on?
I've noticed that VSCode + the JSX plugin, when run concurrently with webpack in watch mode, cause my machine to thrash. Working theory is that they are both watching the large node_modules folder, but yet to confirm.
Not surprising since most people have their own pool of extensions that they'll install but fail to mention any time the topic comes up. This is the "Firefox is beastly" strain of criticism all over again.
It is probably an issue with your video driver. No text editor should feel laggish right off the bat. The open source Radeon driver is prone to sluggishness.
It has more to do with the Monaco editor (the web-based editor that you see in typescriptlang.org as well as VSCode). Monaco as an initiative has been around for longer than Atom, I think (?)
Ask that to the IDEA and Eclipse folks. Certainly chrome feels smoother to me than either of them do on equivalent hardware. And if we pop over into desktop linux, it's even more one-sided towards browsers.
I absolutely love how VS Code generally feels more native, performant, and polished than Atom, but lack of a good VIM mode is keeping me away right now. Hopefully the author of VIM Mode in Atom, makes a VS Code plugin.
The issue with Vim is that the editor has several hundred/thousand idioms and everybody uses a different subset. As an example, most people delete words with `dw` while I usually use `dt<space>` because the t/f motions generalize to subwords. Until you have the majority of your personal subset implemented, vim support in a given editor is "bad".
I've thought about doing a vim implementation for years where motions are expressed as composable functions projecting from text range to text range with commands taking a list of text ranges, mostly because I'd like to whether non-text based motions (e.g. AST based or generalized cursors) would work. I like VSCode and expect to move over to it so I've thought about starting my project but the scope of doing a good implementation is daunting.
Congrats on the 1.0 release, VSCode is a great product.
So essentially, I think vim-mode in atom actually uses NeoVim's headless VIM engine, which is why it's more full featured. But don't quote me on that :)
The ideal VIM mode plugin for VS Code would do the same.
Still no CLI mode for editing text. Vim has had this for years. How am I supposed to integrate this behemoth into my work flow if I can't even run it in a terminal?
It's just too clunky for my taste.
It's also hilarious that Atom gets shat on for data collection when no one cares that VS does it too. Microsoft can do no wrong, only OSS projects have standards to live up to.
Have you tried Vim 8? One of the major updates is plugin package management. Can't say much about it, haven't upgraded yet, but the write up on it looks promising.
Have you? Or did you read the placeholder document for a version of vim that isn't anywhere near ready for general release? Because if you know where a branch or a build of vim 8 is, I'd appreciate a pointer.
No, as mentioned above I haven't. And yes I read the announcement on HN a few days ago. Again, I haven't tried it, just going off of Bram's comments regarding new features.
Sorry if I sounded like I was endorsing it. Did you not read my comment?
Can't say much about it, haven't upgraded yet, but the write up on it looks promising.
You're asking for VS Code to be a completely different product. VS Code is a GUI text editor like Sublime and Atom. There's no reason for it to run in a terminal. Vim and Emacs are classical CLI based text editors. Are you asking for an alternative to those?
Yes, they're both text editors, but they're completely different classes of text editors. MS Word is also a text editor, but it would be ridiculous to fault it for not having a CLI. It's nice that Emacs and Vim have GUI modes, but I doubt they're the primary way users use those editors. Emacs/Vim and VS Code/Sublime/Atom fulfill different needs and preferences.
I'm curious about your answer to this: would you argue that MS should combine Word and VS Code into one text editor?
Normally I'd be the first jumping on Microsoft products and criticize them but this is a strange statement. Most of what you can find in VSCode runs on nodejs so if you want a specific features in a CLI you don't need VSCode, just install whatever nodejs lib you need and use it from the CLI.
Great story from Microsoft. Personally I use [neo]vim but I often recommend Visual Studio Code to my non programmer collegues. I think it is really user friendly.
I guess it's not Textmate VS Sublime Text anymore. It's VS Code versus Atom. While it's always good to have some competition, I also hate it to see awesome features present in one, but not the other. Well, if I'd have to pick one (and actually the only one that kept me with Sublime for this long), it would be speed.
I'm a longtime Emacs user and I dabble with atom and code. The main thing that I get out of GUI editors is that extensions generally just work. I spent a lot of time debugging emacs extensions to the point that I kind of expected extensions to not work right when I install them - especially ones related to autocompletion. Nowadays I use spacemacs to keep my package management sane, but it's inflexible and complicated.
I miss things from Emacs sometimes so I keep it around. I miss macros, I miss some of the more stellar Emacs packages (Tuareg for OCaml and Cider for Clojure in particular) but I do a lot of editing nowadays in Atom and Code.
I'd say that's almost true. I'm also a longtime Emacs user. My work development is C# on Windows, so I've dabbled with VSCode and Atom.
My experience so far is that extensions on VSCode "just work", but they're scarce, and difficult to discover and install.
My experience with extensions on Atom is that they are numerous, cover a very wide variety of needs/wants, and that they frequently break when the main editor updates. I haven't been able to install/update the Omnisharp extension successfully since the npm debacle a few weeks ago.
I dabbled with Spacemacs, and it seems nice, but I couldn't work out how to migrate my existing extensive org-mode customizations without digging deep into the Spacemacs package management system.
I'm an emacs user but I often use a GUI IDE when it makes sense. I find I'd rather use JetBrains products (PHPStorm, PyCharm and IntelliJ) even though the actual text editing part is nowhere near as powerful and efficient as my Emacs setup. Sometimes if I need to do some repetitive or monumental editing task that I could script in emacs or use the macro system, I'll switch over for a moment. The benefits of being in an environment with a debugger and many other tools as well as project management and auto-completion that is consistent across the languages I use outweigh the cons of leaving emacs.
I'm considering switching to Visual Studio just for a React Native project I'm working on because it seems to handle Javascript/JMX much better than anything else I've tried.
I'm still living in vim-wonderland, but GUI editors are more flexible in what they can show you. Underline invalid code, auto-complete, ctags pane, file view pane, etc... are all things that tend to work better in a GUI. Other things are plain impossible in TUI, such as minimap view of the file[0], or bracket's contextual popups[1][2][3]
What I'm really looking for is something like Atom's Neovim Mode [4], allowing me to use Atom's flexible UI (hey there, CSS) with vim's modal editor, wealth of plugins, and my config (keybindings, etc...).
I have, and the biggest benefits for me have been:
* Intellisense - this is *incredible*, and it works out of the box with VS Code
* Git stuff is pointy-clicky integrated...this is a big time-saver for me, since I check stuff in just a few times a day, and I don't have to think at all about git commands after writing a bunch of C#. I can click my way through instead.
The interface is a lot more attractive to me than Emacs has ever been (or will ever be), and I really appreciate how easy on the eyes it is, both in terms of eye strain as well as a pleasant visual style.
I'm also pretty comfortable using a mouse--i.e. I don't feel the need to keep my hands on the keyboard at all times--because, when it comes down to it, I spend a lot more time thinking than typing.
I use both VS Code and Vim very heavily every day and, honestly, there aren't really any gains or losses when switching between the two.
I use VS Code when I'm working in one codebase because it has a nice tree view of the files and has a pretty nice "working files" feature where you can easily switch between files you're working on (I usually have five or six files I'm working on at any given time; sometimes in Vim I'll open them all up in a terminal multiplexer and switch between them, but that can end up frying my brain). Seeing the tree structure just helps me visualize the codebase better. VS Code also has a really nice search feature that searches through every file in the folder you have open (I could just grep but it's convenient to click on a result and go straight to the line in that file)
Git integration in VS Code is pretty sweet as well; it has a really nice diff viewer built-in and it's easy enough to add and commit changes (I still use the git cli for branching, rebasing, etc.)
I use Vim whenever I'm in a terminal to edit various files here and there. I feel a little faster in Vim when working on one file, and I do like a lot of the shortcuts/commands a lot better in Vim. Vim also has much better find/replace with regex, and it's a lot easier to extend Vim.
I guess what I'm trying to say is that I don't see VS Code as a full-on replacement for Vim, but a different tool that I use in a different way.
I have moved part-time from vim to vscode, for Go work.
Some reasons:
- Having the full type info for every single thing in the code with simply hovering over it (not just when typing)
- Ability to "peak at definition", to get a little interspersed window with the definition of functions etc,
embedded right into your editor.
- Out-of-the box file tree with single click opening, and window management (I use a lot of powerful vim commands, but window management just was too much for my head).
- Maybe something more I've forgot.
In general, the out-of-the box experience is so much greater than vim. I know you can replicate most of the above with a super-fancy setup, but I just don't find the time to get my head around much more than http://github.com/fatih/vim-go and a few personal .vimrc tweaks.
Now as others have mentioned, I just hope for a more feature-complete vim-mode in VSCode.
I really wanted to use VS code with Python so I could use the debugger, but configuration see magical. I really want to like it. In the end it seems that my Django project is configured to kill VS Code when it starts up, even the menu hangs.
It might be nice editor, but it hide to much information for my taste. "You need to setup a launch.json file", well fine, but at least be a little more helpful than that, don't just open an empty file. Starting the debugger either crashed the editor or do nothing, but never informs me as to what the issue might be.
At this point Vim and shell is easier to get started with.
I use vim, but Atom now primarily. Atom because of plugins: Beautify, Minimap, Markdown Preview, Convert css-to-inline, editorconfig, easy to split windows, and easy to search for text in whole directory. VSCode can't split windows horizontally but it has a nice node debug. However I usually just "node debug" in the terminal. Atom also has a Racer plugin which is nice for Rust.
I don't get this false separation. Vim is, mostly, the best way to edit text, no matter the editor. Other things, like VS, Emacs, etc. are just ways to organize how the text editor interacts with other stuff (windows, IDEs, etc.).
Why not both? I use Emacs+evil. I use VS+VsVim. I don't understand why this isn't the preferred mode for everyone? Pick the best environment/shell/whatever, then make sure it uses vim for actual text editing. Problem solved.
Visual Studio Code could serve as a solid base for VS.NextGen. Following previously unheard-of paradigms (Unix) for Microsoft, Visual Studio could actually become modular, with each component becoming useful on its own.
Visual Studio Code would be the editor, Omnisharp the Intellisense platform, I think they were also developing some sort of common debugging interface, etc.
It would be a lot nicer than the current Visual Studio setup, where the installation drags in 6GB of cruft.
Of course, this would involve an internal power struggle between Visual Studio Code and Visual Studio proper, and I hope VS Code wins :)
I have a gut feeling that this is in fact the plan. People keep asking "When can we have Visual Studio on OS X/Linux?", but I don't think that's ever going to happen: VS is so tightly coupled with COM and Win32 that they'd basically have to write it from scratch, or write an entire Windows emulation layer. But what they can do is gradually add features to VSC until it does most of the things you wanted full VS for: Intellisense, deploy-anywhere frameworks and debugging being the main ones. Doing it that way will probably be more performant too.
They've demonstrated it too. With Roslyn being a "compiler as a service" and the OmniSharp umbrella of plugins, now VS Code and Sublime Text all have the same intelligence (and IntelliSense) that Visual Studio has. Everything else (IMO) is much easier chrome around that fundamental experience, and can easily be filled in over time.
In the C# talk at Build [1], they demonstrated visual debugging using VS code. It was pretty awesome.
VSCode has done the thing that nobody expected MS to do, change the way code was written on Unix/Linux.
I love linux/unix, but the problem always was with the lack of an awesome text editor cum IDE, yep there is eclipse but it is too clunky, I do not like sublime as it isn't FOSS (call me crazy), gedit took way too much memory, geany is fast and mean but the UI sucks plus functionality isn't that great.
Enter VSCode, code writing feels amazing again, not the functional part, but the actual manual part.
I do not like vi because I primarily was learning web dev and I didn't really get my head around using vi effectively and still learn the web dev, so I am not a emacs/vi superstar as I have heard that both of them are fine text editors.
but for the people like me who don't or can't use terminal based editors, VSCode is quite literally the best.
The new Che project of Eclipse does seem promising, but the last time I tried installing it, it took around an hour, consumed GBs of my bandwidth and still nothing.
I am still Waiting for the day I'll be able to program in its entirety on my android device.
I used Atom but it is too slow, it is surprising that VScode and atom share the same ancestor but one is blazingly fast and Atom is so damn slow.
Edit: yep vscode didn't transform coding on unix, it merely changed it to some extent, and why the downvoting? point out where I am wrong, I'll get to learn!
Really? VSCode has already transformed the way code was written on Unix/Linux? I beg to differ. 10 years ago (when I discovered Eclipse, not sure when it was originally released), Eclipse was a staggering leap forward for Java programming. I'm no Eclipse fan, but I don't think that VSCode has already changed the world in the way that Eclipse did, and certainly not in its short lifespan.
I think what the parent meant was that VSC (along with Atom, and to lesser extent SublimeText) is a good example of "the middle way" that is rapidly gaining popularity. First we had console editors, but they weren't powerful enough, especially for newer languages/frameworks. Then we had full IDEs (VS/Eclipse/IntelliJ), but they got to be slow and clunky. Now the trend is toward "enhanced text editors" (VSC/Atom/ST): editors that can have modular plugin functionality and interact with the console so you don't lose any of its versatility. They're usually faster and more lightweight than IDEs but keep most of what you need. The parent is saying that Eclipse was the flagship of "Generation 2" and VSC is for "Generation 3"
And remember, no one is saying you have to use these programs. Console editors and IDEs will still be here. This is another option for people who want it, which has turned out to be a lot of people.
What I'm taking issue with is the description of VSC as "changing the way we code on Unix/Linux". Given your interpretation, Atom and SublimeText and other tools predate VSC and fill much the same role. So I don't see VSC as being transformative in that way. That's not to say it might not be a nice tool, but it's not a revolution either.
I understand; I just think you're being a little harsh on the OP, even if their language was a bit exuberant. They said they tried Atom and found it too slow, so if VSC was the first "3rd gen editor" (a term I just made up) that was usable in their workflow, then for them, it is a revolution. Assume good faith when comments are ambiguous :)
Yep, that's what I meant, earlier I didn't have such an awesome text editor with git inbuilt, eclipse is clunky and stuff, vi and emacs are too hard to learn, didn't have that much time to learn every small stuff that vi can do, so vscode changed the way I write code, and for most of the "new" developers, it will change the way they write code, gone are the days when you are staring at the screen wondering what was that shortcut. at least for developing webapps
Eclipse is not a code editor. It's an IDE. It offers a bazillion things out of the box (a lot of it that VS doesn't do without Resharper), but you're going to pay the price in terms of performance and RAM, sure.
I do use vi, it is amazing, but if I want to develop a large web app then I'd rather use vscode and use vi when I am in the geek mode and don't have to manage a lot of files. Thanks for the tip :)
What part of the IDE's is slow and clunky. Is it just startup you're talking about or other parts? I'm a heavy Intellij user as well as vi user and, apart from startup, don't notice any speed differences.
When you've got 10 subprojects open and every few new lines of code you save your file, resulting in a build triggering a cascade of plugin actions and more than a few seconds of mouse spinning, then yeah IDEs are slow and clunky.
When my IDE stops working one morning because yesterday's system crash resulted in a plugin being unable to load properly and subsequently peppering me with dialog boxes or worse, crashing the IDE, then it is definitely clunky.
When I just want to do code browsing across 500,000 lines of code and it takes 2-3 seconds every time I hover over a symbol just to populate the object list, that is slow.
Your experience sounds great. My experience has been that every IDE configuration falls into rot after 6 months to a year or so and the whole thing needs to be deleted and reinstalled. That's also slow.
Meanwhile, vim+ctags+gdb have given me years of reliable service. More than once I've had an IDE collapse into a pile of errors and turned to my trusty basic tools, only to leave the IDE as the steaming mess that it turned into for weeks or even months as I just didn't need that browsing or inline debugging power at the time.
Have you considered disabling some of those plugins? the functionality they give you is not worth the performance hit. Using an IDE does not mean you can't use the terminal at all.
It seems to me that if you were to disable the plugins, then you're kind of back to the equivalent of vim+ctags+gdb functionality. So, when saying an IDE is slow and clunky compared to an editor aren't you comparing apples and oranges?
> First we had console editors, [...] Then we had full IDEs [...] Now the trend is toward "enhanced text editors" (VSC/Atom/ST): editors that can have modular plugin functionality and interact with the console so you don't lose any of its versatility. They're usually faster and more lightweight than IDEs but keep most of what you need
Emacs has functioned as an "advanced text editor" for at least 20 years and probably longer. There's a very common misconception that Emacs is a "console editor", but the reality is that when you first launch it in a windowed environment you get something that looks an awful lot like Sublime, VSCode & Atom: a text editor window with a menubar and toolbar similar (yes, it's not perfect!) to what you'd expect from any other editor native to your chosen platform.
The time investment involved in learning how to use it is also considerably less than implied elsewhere in this thread. In fact I really doubt that it's significantly more than you'd have to spend educating yourself about any other "advanced editor"'s configuration, keybindings for non-obvious actions, extension mechanism, etc. It's easy enough to learn the (admittedly unconventional) keybindings for a handful of common things like opening and saving files when you have the menus to refer to, and by default it'll even open a buffer containing clickable hyperlinks to helpful things like tutorials. I still haven't seen an editor or IDE with better built-in help.
Even configuring Emacs isn't all that hard: there's a built-in interface for installing packages, most of which will pretty-much auto-activate once installed (i.e. less need to mess around with elisp), and for changing configuration there's "customize", which is a nicer way to change configuration variables than just editing a JSON file. When you do have to start writing some elisp code (you'll almost certainly have to write a little) the documentation is superb and there are more than enough resources on the web to help you. A programmer who is already familiar with a dynamic language like JS will probably have less trouble learning elisp than a C programmer did 20 years ago.
None of which is to say that there aren't areas where Emacs isn't behind. I'd like to see better support for projects, snippets and auto-completion out of the box, as well as being more nicely pre-configured for popular languages like JavaScript and Python. Emacs 24 is four years old at this point, and that's a very long time for any developer tool to stay still.
These days I'd say the most confusing thing about Emacs is working out which of the many competing packages you should choose for whatever it is you're trying to do. Age is working against it here, because what was the almost-universally-recommended package five years ago - for which you'll get plenty of helpful google search results - has often been superceded by something better.
But with a handful of plugins installed (yasnippet, helm, projectile, auto-complete) it's (IMO of course) still the best editor out there.
Emacs doesn't have tabs. You can spin that any way you want: that tabs are an inefficient system, that tabs are limited, that Emacs offers more powerful systems but right now Emacs doesn't offer non-manually managed tabs respecting the tabbed interface convention found in any mainstream editor or even mainstream application (web browsers, etc.).
I kind of agree with this. The thing is, Emacs has always been "Generation 3" in your terminology. Atom and VSC are kind of bringing the Emacs way (extension language is implementation language, not restricted to a narrow plugin API) to a new generation, along with the graphical experience that Emacs doesn't provide (yes, I use GUI Emacs. Yes, Spacemacs is nice. Atom with Material-UI plugin is still prettier).
I'll be an Emacs user for life, but I am currently recommending Atom to people wanting to move away from language-specific IDEs and dabble in a text editor, because it has enough of the Emacs nature while not being too daunting.
I use Visual Code for Golang, for everything else Linux has other stuff that's better imo. Like Netbeans and PyCharm. Seems like I should be using it for TypeScript.
How do people put up with VS Code and laggy text input though? I used it on Win10 and Linux and both occasions there is noticeably lag when typing.I look at the screen while I type most of the time and this lag makes coding impossible for me because I like to see what I'm writing in real time.
I've noticed this happen especially on big projects/files.
Also, sometimes the auto complete popup is very slow to appear and causes lag.
I don't use many GUI text editors and have not compared VS to Atom/sublime, but for me this is just unacceptable.
Agreed. I don't see anything in VSCode that's not present in any of the vast array of alternatives. But then again, I live in IntelliJ and Emacs land. I don't mind Atom but don't really use it for anything.
Light Table might deserve the term "transformative", but I didn't find it usable enough to rely on.
I've been using both Atom and VSCode over the past few months and gradually got to the point where I just prefer VSCode. It's hard to pinpoint a specific reason, but it feels faster and a little more polished.
Nope. Visual Studio Code was created before Atom.[1] Although both VS Code and Atom are based on Electron[1] and are both Chrome-based. VS Code does seem to be stealing Atom's thunder as what they say [1]
Yeah, but point is, it wasn't released until 2015. Which is the part that matters. Who cares if they started developing something tangentially related to it 2 years earlier. Atom came out to the public first, and that's what matters in terms of plugins and such. I never heard anything about people making Monaco plugins, did you? VSCode was basically released because Electron came out. From the Atom devs. So while Monaco may have come first, VSCode certainly did not. And Monaco didn't offer the sort of things that VSCode and Atom focus on - namely community plugins.
it starts with the speed, atom is clunky and slow. If I do not have any other alternative them Atom is good enough, but geany and vscode are way way better than atom. I'd rather do all fancy plugin stuff of atom using python and use geany than use Atom because of its slow speed. I wonder why anyone isn't doing anything for that considering github is the company being atom and that vscode and atom both are based on electron yet vscode is so damn faster than atom
Also: Doesn't ask me to save my unsaved files when I close the editor. Sublime Text called this feature "hotexit", but in Atom there's no way to disable it.
Atom is great in many ways, and I personally don't have any major complaints about speed, but it disappoints me in lots of little ways. For example, on two different machines, when I upgraded to 1.7.0, Atom failed to reopen my open tabs - they all became 'untitled'. And a couple of them were unsaved (my fault, of course, but I hadn't ever been burned by Sublime doing the same drill).
Ummm, no. VS Code is a decent editor, nothing more. It certainly doesn't transform the way code is written on Unix/Linux.
Vim and Emacs are still superior if you want to put the time in, and both have non-terminal interfaces. They can also be both customized to be whatever you want them to be, there's not really a limit to their functionality except what plugins are already written. Ditto for Atom, though of course, it does seem to be more web based for the moment (though Atom does have great plugins for Go, Nim, and I'm sure a bunch of other languages).
In the grand scheme of things, tools like compilers, debuggers, interpreters, other command line tools (like completion servers), etc..., matter more than editors anyway.
Edit - for the record, VS Code seems great. But it's not revolutionary.
That's what, gone are the days when we'd spend hours and hours to learn the little little ways of vi and the myriad functions in emacs. Now we need to get things done, can't afford to sit down and study the entire functions of vi and emacs. I don't mean to troll but after switching to vscode and the go plugin I learned go webdev and wrote this small intro book,
http://github.com/thewhitetulip/web-dev-golang-anti-textbook...
That is the power of vscode, it provided a good enough way to play with code, yes not outright innovation, but an awesome text editor nonetheless.
Atom has a great Go plugin: linting, context aware completion, fixes code style on save, etc..., all powered by Go's command line tools.
I'm not saying Vim and Emacs are the be-all (I program mostly in R, so RStudio is my main tool), only that VS Code hasn't changed anything fundamentally. It's just a good editor.
Well, okay, let's talk about that. Is having source control in your text editor enough of a benefit to one's daily routine as to be a step change of productivity or quality of life? It may be for you and I'm not saying you're wrong for that, I'm asking because it isn't for me; I have an alt and a tab key.
Bear in mind that the claim wasn't that it's better in some ways, but that it's sweepingly better than the stuff that came before (and Atom wasn't even mentioned by the OP, which is funny--I mean, I don't use it, but it's obviously in the conversation).
"Well, okay, let's talk about that. Is having source control in your text editor enough of a benefit to one's daily routine as to be a step change of productivity or quality of life?"
Uh, if you edit tens or hundreds of text files per day, it's a game changer.
Having the git diff in your editor gives you syntax highlighting and let's you edit it (the right side) like you're used to.
I guess the killer feature of VS Code is multiple cursors (Ctrl+D). I only know of Sublime Text and Atom who also have this feature on Linux, not sure about Kate. Sublime Text is closed source and not gratis, Atom is slow and buggy.
Not allowed to reply to your post, so replying here.
No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.
That they are not built-in really doesn't matter though. All these editors revolve around plugins, and it's common practice to save your preferences on github or the like so that it's easy to use the same settings and plugins on every machine.
> Not allowed to reply to your post, so replying here.
I think you have to wait a few minutes, then it gets activated.
> No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.
That's too complicated for me. Last time I've tried to set up vim and emacs to my liking it was a mess: A lot of copying and pasting around random code, changing configuration files I didn't understand, ...
In all respect, but you are presumably a software developer. If someone approached you saying that language x is a mess, as they've copy-pasted around random code and changed configuration files they didn't understand. Would you accept that as valid criticism or told the person to actually learn their tools?
Granted, Atom, Sublime, VSCode etc. are easier to start with because they expose customization through JSON files instead of a custom programming language. But if someone where to tell you that they didn't understand how multiple cursors worked in VSCode, you would tell them to learn their tools and send them a link to the relevant page of the documentation (if that).
If you know your editor, adding functionality like multiple cursors is easy. The greatest strengths of extensible lightweight editors like VSCode and Emacs, is that such functionality is only a package away.
> they didn't understand how multiple cursors worked in VSCode, you would tell them to learn their tools and send them a link to the relevant page of the documentation (if that).
No that's the thing: I would tell them to press Ctrl+D, simple as that. Multiple cursors in Sublime Text, Atom and VSCode are intuitive and it's the first time in an editor that I actually use them.
For me it does, depending on the project. (Using emacs/magit, having a dedicated buffer just for magit.)
I want to keep on top of my current branch, what is untracked, what is unstaged and staged, quick diffing, etc. It actually helps a lot with productivity since I don't have to actively query for this information when it's all in one screen.
If I used another editor, I would like to have similar features. Maybe it can be done, but I am quite fluent in magit already, and one major thing keeping me from moving to another text editor for my current projects (if it actually mattered.)
This is something I really do not understand. I can switch to my terminal, build, run, stage, commit, push all in like 5 seconds. As well as anything else I need to do in the terminal.
The only 'plugins' I use are a keyboard shortcut (cmd+space) which puts me in a terminal window and rupa/z[1] for jumping into a project directory.
Let's say you look at `git diff` and notice something needs to be changed. What do you do now? You need to quit, open the file, find the line, do the change, save and quit. Now you need to reopen git diff and scroll to the old position. This all takes a lot more than 5 seconds on the terminal.
Another scenario: You type `git status` and see a file called `src/a/very/long/path/file.c` hasn't been staged yet. Now you need to type that file path for git add or git diff. Takes more than 5 seconds, but it's just a simple click on a + symbol in VS Code.
1. atom is slow and clunky it hangs when I paste a 10000 line sql insert statements
2. sublime text: sorry didn't try
vscode's benifits:
blazingly fast
modern design
works on linux/mac too
little features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there.
It is a great way to code if you don't want or can't use vi/emacs, I don't have the luxury to learn all the nook and corners of emacs, I started using Go plugin in vscode and today I have built go apps and written partially completed book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook...
i tried giving vi a chance, but nope. couldn't bear it for more than a day, large webapps require a UI IDE, vscode > everything else I tried till now
> blazingly fast modern design works on linux/mac too little features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there.
Literally every other popular code editor supports some form of "go to symbol".
"Some other go to symbol"
It is obvious I didn't use intellij and pycharm and stuff like that, but the ones I did use, kate, gedit, eclipse, notepad++ didn't let me drop into a function "With ease"
yeah you can use that feature in eclipse, but it isn't with ease, maybe it is because I am so biased for vscode. We'll never know, but the thing is I feel productive typing into vscode than I ever had with some other editor I tried.
Go ahead and downvote it, but after all every programmer worth his/her salt does realize that the choice of IDE/text editor is ultimately a personal opinion, so long as you as a person are comfortable using it, that is good for you, it does not make a tad bit of difference to anyone else in the world.
> features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there
>Vim and Emacs are still superior if you want to put the time >in,
TBH, not every developer is willing to become a power user or interested to learn an IDE instead of the language itself. Being someone who worked on VStudio alot and now on Linux/Mac based tools, I can safely say that Microsoft tools are Developers friendly most of the time. It's good they are introducing same touch for Linux/OSX community.
That is fine, I think it is great that IDEs exist for easy editing and debugging. But power users will always exist in the programming community. These people will naturally use Vim and Emacs because they support the customization levels needed for complex programming workflows.
In my experience novices have an easier time learning programming with an intuitive IDE, but experienced users use whatever makes the most sense given the task at hand, which in many cases might also be an IDE. They're just different tools with different pros and cons, and each of those pros and cons are weighted differently depending on what you're trying to accomplish.
Very few programming workflows are so complicated that it is simply not possible to do something without first creating your own highly customized environment within Emacs. However, very, very many programmers do have a lot more fun screwing around with customizing their work environment (editor, window manager, shell, etc.) than using that environment to get actual work done (myself included).
Which is not to say that Vim and Emacs aren't awesome tools, I just wouldn't generalize anything about anyone based on the tools they use.
One thing that is not immediately obvious about vim (or evil Emacs) is the gamification part. Before I switched to Spacemacs myself, I used to think -- why do those vim guys torture themselves using an old deprecated tool. Now I actually find it fun to edit text or code and think of how much everyone else is missing :)
The best possible programming environment is comprised of emacs coupled with a "lispy" language such as Common Lisp, Scheme, Racket or Clojure and the REPL to go along with it.
And the somewhat sad thing is that this is only a shadow of what was once possible on Lisp Machines... In some areas, we really did make a big step back over the last three decades.
"a few hours" ??? Come on, let's not pretend that EMACS is going to take "a few hours" to come to terms with and become more productive in than an IDE.
I actually switched from VS to vim (while doing a project that integrated ironruby and C#). It took me about a week to reach 75-80% effectiveness with vim. At the end of 2 weeks I was back to full speed. At the end of 2 months I was considerably more effective at editing code. I'm now several years and several jobs removed from that initial project and I can't imagine not using vim.
I switched to Emacs (Spacemacs) from Sublime Text with zero prior knowledge of vim or Emacs. In a day or two I could continue doing what I was normally doing. In a few weeks I felt completely comfortable.
My 13 year old daughter came up to speed with emacs in a couple of hours. Now she's starting to realize she can make it into whatever she wants and make it work however she wants. She hadn't even thought about being able to program new functionality into an application. It's opened whole new worlds for her. Yes, emacs.
Actually, you can get decently proficient in just few hours. Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?
Humans have this funny thing as they grow older - they look at a thing, maybe try it out for few seconds, and then immediately determine it's too difficult and it will take forever. They rarely bother to spend actual five minutes, to the clock. If they did, they might actually have learned something.
25 minutes of deliberate practice - a single Pomodoro - is enough to become acquainted with several of Emacs features - like, navigation by semantic units and incremental search and autocompletion. You won't get proficient in that time, but it's enough to rewire yourself to actually start using it when writing code. Which will then lead to you becoming proficient while doing your regular, billable work.
Seriously, set up a Pomodoro timer, sit in front of Vim or Emacs, and try to practice a few things. You'll be surprised how fast you can learn.
(And yes, I did that, so I'm not talking out of my ass. I actually almost doubled my Emacs productivity once in 5 pomodoros - in 2.5 hours - two of which I spent watching Emacs Rocks videos, two on rewriting s-expressions with Paredit, and one on multiple-cursors.)
Actual proficiency in emacs takes time, a lot of it, and practice, a lot of it.
To reach a level of skill where using emacs is easier/faster/better than something like intelli-j (for instance) requires significant dedication and repetition.
> Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?
Not parent but I have. I still would recommend something else for all the stuff I work with.
That said, it is amazing, I just believe in my line of work people are better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.
> I still would recommend something else for all the stuff I work with.
I sometimes do to. In particular, when that stuff is Java or C# - it's hard to beat the support IDEs gives you there. So I personally opt to switching said IDEs to Emacs keybindings instead.
(Also, one could argue that you need IDEs there mostly as crutches to support the weak language, but that's a topic for another day...)
> better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.
Refactoring - if you mean semantic transformations supported by your IDE, then yes. See above. But for search/replace and block selection no IDE beats the convenience of Vim and Emacs. They simply can do that better and more naturally (along with plethora of similar things helping with selection and navigation). And this is exactly the type of thing I was talking about in my previous comments - you can learn both under one Pomodoro if you focus solely on it, and then normal work will quickly take you to proficiency.
I've used emacs as my main text editor at work for the past 9 months, and I can safely say I am still nowhere near proficient. I'm getting better, but I can fully appreciate why emacs has the reputation it has.
> Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?
Not the parent, but I've spent a significant amount of time with pure vim. I use vim bindings in everything from my web browser (vimium, vimperator) to my WM (i3 & kde vim navigation bindings), to my text editors & IDEs (atom, VS, sublime)
Despite all that, I still find using pure vim to be ineffective relative to just using Atom, Sublime, VS or whatever with vim bindings. I may have internalized the most basic navigational concepts, but the more advanced / esoteric shortcuts that are essential to use vim as an exclusive editor are still ones I need to look up - and that's not counting stuff specific to vim packages liked nerdtree.
At the end of the day I'm sure you could always argue that I should have practiced differently / better / more or whatever - but to what end? There are plenty of full featured text editors on all platforms that do everything I need. Why on earth should anyone force themselves through dedicated practice just to learn the intricacies of a 20 year old editor?
Because I don't need them, and would rather focus my attention on the part of the job I actually care about. The simplest tool which doesn't waste my time is the best. I have found that I would rather use a simple editor with no features that I never have to think about, and automate repetitive tasks using the same tools I already use for automating repetitive tasks: programming languages.
So... you'd rather spend the time writing new code to do repetitive tasks rather than use existing ones? You'd rather spend time writing 'search and replace' in your favourite language than just use an editor with it? I don't see how that doesn't waste your time.
I'm happy to spend a little extra time every now and then doing some unusual task by hand in exchange for never having to think about the editor or try to remember how some powerful, infrequently-used feature works. As long as the editor can do everything I want to do on a daily basis, I'm happy; if it can also automate tasks I only have to do every week or two or every couple of months, it's a waste, because it'll take some effort to remember that the feature exists, what it's called, where to find it, and how to use it. I'd rather just use a simpler editor and deal with that oddball task in whatever way is convenient when it comes up. Since I spend all day slinging code, bashing up a little script to do some odd code-munging job is no trouble; I already have all the tools I need to do that paged into my working memory.
I was thinking more of the sorts of automatic refactoring tools some people really like to use in their IDEs. I haven't found that such tools save enough time to be worth learning how to use them.
That just sounds like a self rationalization to me. "I don't need them" is something you say after you tried something and realized you actually don't need them. It doesn't carry any weight when you haven't even tried. Because when you do, it's just saying you don't want to try new things. I'm not saying you must learn these, I'm just saying you shouldn't lie to yourself.
That's a little harsh, but the cognitive bias you're describing certainly is a common one, and it's one I struggled with a lot when I was younger. I've learned to manage feelings of fear or anxiety by reinterpreting their activated, buzzy feeling as excitement or anticipation. This works well, though it has turned me into something of a daredevil...
I really don't think that's what's behind my attitude toward code editors, though. I've been writing code for thirty-odd years and making a living at it for twenty-five, and I've spent the majority of that time working on dev tools. Compilers, mostly - but I've written a couple of editors, too, plus a debugger, a couple of linkers, an assembler, you name it. So I have had a lot of time to think about tools, and have been lucky enough to get several chances to put my ideas into practice.
I'd have trouble remembering the names of all the different editors and IDEs I've used over the years. Emacs and vi are ubiquitous now but that was certainly not always true, and on some platforms, particularly embedded environments, using anything but the officially-blessed toolchain can make your life unnecessarily difficult. I have learned to get my work done using whatever tools happen to be on hand. That's meant a wide variation in the kinds of features which are available, the specific control-key bindings, the details of the build environment, pretty much anything you can imagine - so I have learned to rely on the basics and ignore the rest.
I find it far more frustrating to deal with a sophisticated tool that isn't working quite right than a simple, brainless tool that does the job but requires a little extra manual labor.
I'm not here to play with editors, after all, I'm here to build software, and the editors are just a means to that end. Time spent learning sophisticated editor features has to justify itself in time reliably saved using those features, which has to be balanced against the time wasted when they don't work quite right or when you have to go dig through the documentation to remember how to use them, times some distraction multiplier for the fact that you're thinking about the tool instead of the job you're using the tool to do. In my experience, there's been too much change and not enough actual need for sophisticated editor features to justify their cost.
Even if a sophisticated editor could allow me to perform certain editing tasks more quickly, that wouldn't change my overall productivity very much at all, because I spend far more time reading and thinking than I spend typing or editing. I type fast enough already; it's my brain that needs to be accelerated, and the best way I've found to do that is to eliminate distractions and focus as much as possible on the problem I am actually trying to solve.
I wrote a simple terminal-based editor a couple of years ago, including all the features I use every day and none that I don't, and I've been using it for all my daily programming work ever since. It's an unabashedly personal expression of my own taste, so I wouldn't necessarily recommend it to anyone else, but I like it and feel good when I use it. It's nice to know everything there is to know about the tool, so that I never have to think about it or try to remember how it works. Perhaps some day I'll be working in some new environment with some new toolchain and I won't be able to take ozette[1] along with me, but that's fine - wherever I go, I'll be able to get my work done with the tools I find there, because I'm comfortable doing my job with the basics.
Vim is a language to edit text and you can use that language in a lot of development environments. if you code all day it's worth learning.
verbs like ci" (change inside ") which deletes inside the current double quotes and leaves you in insert mode are pretty easy to get used to. dd deletes a line and puts it into the yank register so you can paste it somewhere. u undos an action.
using a plugin with visual studio is pretty king to get the best of the IDE and the most common vim functionality.
> I can safely say that Microsoft tools are Developers friendly most of the time
You only think that because you have used it and became accustomed to vstudio. As someone who has used vstudio, eclipse, atom, intellij, vim, emacs - I can safely say that vim and emacs are far more 'developer-friendly' than the others.
Because the low-level modularity of Vim and Emacs gives you more control, by letting you choose the combination of tools you use ; instead of tying together the language(s), the compiler, the tag/completion engine, the build/project system, the debugger, the profiler, like many IDEs do.
The sole concept of IDEs specialized for one language makes me cringe.
> The sole concept of IDEs specialized for one language makes me cringe.
Can you explain this a bit? I don't see that Sublime, VS Code, Atom, etc. were made for one language, at all. As a little background, I've used vim for a while, then switched to Sublime Text, and am just trying VS Code. I find Sublime/VS Code/Atom to be far easier to customize than vim.
This is not what I said: I consider Atom and Sublime Text to be advanced general-purpose text editors, not IDEs.
I was indeed referring to Eclipse and Visual Studio.
From what I observed around me, for some reason, people don't use these to edit:
- shellscripts/perlscripts/batchfiles.
- Files written in a in-house domain-specific language.
- Configuration files.
- Makefiles and project files: vcxproj, sln ...
Actually, I observed that these kind of IDEs discouraged people doing the above things, giving them the impression that it's not "real development" (I suspect that this is, in part, where the bizarre term "scripting language" comes from, but this is another debate).
I am a long time Vim user but I have never ever managed to get c++ tag completion work consistently there. At some point I just stopped trying - went to Qt creator and turned on Vim plugin there. The experience (for C++) is just vastly superior. The IDE integrates with CMake natively, the debugger is graphical and works, the symbol navigation over all project is blazing fast, I have real refactoring etc...
I still use Vim a lot, for JavaScript, for text, for remote sessions... But when a tool with real semantic highlighting and understanding of code is available (with a Vim plugin) then I'll take that.
Unless your project uses CMake, YCM is really hard to set up. You basically have to write a parser for your build system and plug it in.
And that doesn't solve the problem of having one file compiled with different flags, which happens frequently.
And it won't do completion in headers because those aren't actually compiled.
It all really comes down to Vim not having the concept of workspaces and projects - Vim only views files as the filesystem sees them, rather than as your build tools see them. That, to me, is Vim's greatest failing and biggest source of gripes.
It makes sense that if you program a lot that you will learn how to save time in the long run. It took me a day or two comfortable enough to be efficient in it, at least as I was with Atom. After the first few days, you will just learn new tricks while you are programming.
You will see that after you learn how to use Vim you won't want to use anything else to edit text, you emails, browser and word processing will be in Vim.
What I meant was that if you don't have the time or inclination to learn the myriad ways of vi and emacs, there isn't a really great light weight fast text editor, eclipse is too damn slow. so beyond eclipse, there is this great text editor which has great design. we never had the great ctrl+P option in eclipse as far as i can remember where you can jump to definitions, say I have a 100 files project and I want to change the GetUseFunction then I ctrl+P and type the function names, it tells me all the function names and lets me go to the function name directly.
I am not aware if that feature is available in other editors, I tried light table for a short time, but it isn't getting much attention since they are working on some other product. ctrl +P transformed the way i write go code, now I dont' have to bother to remember which file stored what, just ctrl +P function name, as i know what all functions I am using or I can just scroll!
Ctrl+P was taken from Sublime, which in turn took that from TextMate. I think.
VSCode and Atom are essentially just Sublime Text with Javascript instead of Python as the plugin language. Also, IntelliJ has had this for quite some time, though it doesn't meet the criteria for light weight text editor, it is certainly better than Eclipse.
You put extensions into the proper folder, or use a tool like 'Vundle'. Yes it's slightly more difficult than using Atom, but anyone who can use a tool like Git or Cmake should have no problems figuring it out.
While I do agree that VS Code is nothing revolutionary, suggesting Vim and Emacs are superior at this day and age makes no sense. Becoming effective at using these editors is very hard and not practical when there are so many other things any engineer worth their salt has to worry about. Most plugin systems for these tools are a nightmare. Vim has about three or four different plugin solutions and they all have different caveats.
While I agree with regards to Vim, I don't really see how Emacs is hard and impractical. It doesn't have modal editing, you just open a file and write, and the plugin system is built-in.
I do, however, agree with you. Mostly because you can customize Atom and VSCode to have all the same benefits as Emacs and Vim. Except for running them in the console, which I know some people like having the option of doing.
I think the parent was talking about modern text editors such as Sublime, Atom, Brackets etc.; Vim and Emacs are completely different beasts (note: I love both).
Within the category of modern text editors, VS Code is in my opinion revolutionary in several ways - I will give you three examples
The first feature that I find "disruptive" is the way VS Code offers a standardised interface for debuggers, hence debugger plugins are much easier to create - and you can see that VS Code already has debugger plugins available for many languages: https://marketplace.visualstudio.com/vscode/Debuggers?sortBy... the availability of such plugins for Atom and Sublime Text is not nearly as good.
The second aspect where VS Code changed the game is the clever way it leverages Electron (the framework it's made with, Atom is made with Electron too) - while creating clever workarounds to known Electron bugs - e.g. VS Code, unlike Atom, does not suffer from this bug https://github.com/atom/atom/issues/10720
The third aspect is the git integration - since Atom is sponsored by Github, you would think it has the best git integration out there - but VS Code has gone the extra mile by giving you a great user-friendly UI interface for staging and committing (yeah, I know, anything more complicated than git add -A requires the command line - the fact is that nearly 50% of all the git commands I type are git add -A, LOL).
PPS I totally agree with you about the importance of tooling. But e.g. if you have a debugger that does not have an interface to your editor it becomes hard to set breakpoints. So the editor needs to integrate with your tools and VS Code is great at that.
I used emacs as my primary editor for 22 years but switched to clion last year for c/c++ development and am thinking of switching to pycharm for python stuff.
I still use emacs for quick editing, moderately complex search-and-replace in limited numbers of files (for when I don't want to bother with perl), and a handy scratchpad for throwaway things, but I don't intend to do a lot more software development in it anymore.
So, as a 20 year user of emacs with a .emacs file older than some people who post here: I have moved away from both.
I like being able to use other languages for editor extension, having a competent graphical and text layout layer with image support, and quite frankly I find emacs development tedious now.
So... Do I need a few more years of time to "get it?"
Compared to Vim's learning curve, the Wall from GoT is just a small speed bump. I have tried to learn vim for 10 years now and just cannot get past the initial stages.
Agreed, IntelliJ IDEA is so good I can't really use other editors for projects. For editing regular files outside of a project I still use vim or TextEdit/Notepad.
I prefer Intellij so much I use CLion instead of Xcode on OS X and Visual Studio on Windows 10.
It probably doesn't. I use MinGW on Windows. Once Windows 10 adds the announced linux support I guess I'll start using that instead. :)
I can build .exe's that run fine on Windows this way and executables that run on OS X (using the X-Code supplied compiler and build tools that CLion depends on for OS X). I can get qt, wxWidgets and GLFW UIs working for both platforms from the same code base with CLion.
> I love linux/unix, but the problem always was with the lack of an awesome text editor cum IDE, yep there is eclipse but it is too clunky, I do not like sublime as it isn't FOSS (call me crazy), gedit took way too much memory, geany is fast and mean but the UI sucks plus functionality isn't that great.
Atom & IntelliJ?
"gedit took too much memory" - what? It eats like 5-10Mb...
Please, elaborate how VSCode changed the way we write code on Unix? I mean, repeat your statement out loud and ask yourself how big statement you just said. No way in hell how VSCode change the way we write code as much as you stated, no way even Atom did that. Like it or not TextMate came first, and soon after that Sublime Text took over. Yeah, like it or hate it, ST with it’s very well known default monokai theme changed most of the things in terms of GUI Editors for programming.
I mean, what is going on, why people tend to blow VSCode out of the water about how good it is!? I mean, ok it is cool, has some really nifty features I would like to have in some X editor, but no way in hell it is as game-changing as people state. And I really can't see my self switching from Vim to VSCode. Even when I decide to use GUI Editor (I am not HC vim user, for some environments I use it, for others I don't), it is Sublime. I ditched Sublime for Atom since December, and on OS X, it is working very well. Not blazingly fast and smooth as Sublime, but it is far far better than before.
But all in all I am not biting that Electron base for text editor. I mean ok, JS is cool, web is the future, flexible cross-platform solutions are the thing, but it still isn't comparable to native stuff. At least to me, it is getting there year by year but still a long way to go.
At work I write Scala and the IntelliJ Scala support is simply unbeatable. It's refactoring engine etc. is fully Scalafied -- when you paste Java code, there's even a "translate to Scala" function offered. I use a "vim mode" plugin that allows me to hope around with 25j and such.
For my personal project (which is in Rust) I use Atom, which is new for me, but I find to be really impressive. Both its plugin system (which allow for all the extensibility and in my case Rust support) is fantastic, and I don't know where the complaints about speed come from (it's far lighter than IntelliJ, obviously).
I've really been enjoying Atom when I do use it, and don't see why I'd switch to VSCode unless it had better support for Rust. But perhaps I'm missing something.
While I find Atom really nice, and having growing sympathies for it, it definitely feels sluggish compared to Sublime. It is that 0.3-0.7 seconds that make a difference when we are talking about day to day tool usages.
I am a bit turned off by VSCode, it's workflow by the looks of it feel strange to me. Yes I've tried it, yes it was in beta, but right now I am having only Vim on my Mac. Uninstalled Atom this morning, got a little bit frustrated.
It just feels like a web app, I mean it basically is. And when I dragged it to AppCleaner, it is so heavy, 260MB+.
I want GitHub to stream line it. If other were able (look at VSCode for example) that GitHub can. That things leaks memory very now and then. Sublime feels rock solid and blazingly fast compared to Atom, and there you see the difference between native and web. Those fractions of seconds are important when you have app like text editor, especially if used by developers and geeks. :)
So, can VSCode run in a terminal window, without graphical user interface, while ssh'ed into another machine somewhere around the globe over a shitty internet connection, editing a file that's a few hundred megabytes big? As long as that's not possible it's not even a contest ;) I like VSCode because of it's debugger plugin infrastructure, but let's not get silly (MS changing the way code is written on Linux).
what percentage of your coding time do you spend doing things like that? rhapsodising over your text editor is a long-standing unix tradition; no reason vscode fans cannot be part of that!
> editing a file that's a few hundred megabytes big? As long as that's not possible it's not even a contest ;)
I usually try to keep my source files and config files smaller than a few hundred megabytes. Sounds like you might need more specialized tools for your unusual approach to editing source code.
If your development work mainly consists of ssh'ing into remote machines over a shitty internet connection and then editing files that are megabytes big, I think you should reconsider your development workflow.
I realize that's a pretty harsh statement but that really sounds like the worst possible way to go around writing code.
Intellij is an absolute beast of an IDE (in both senses, it's amazing and huge).
I haven't loved working with a tool so much since Delphi 6, it has plugins for everything I want to do, they work really well, I can have a project open and use multiple languages seamlessly, it's extremely customisable.
It's right up there with Linux in my "tools I wouldn't want to live without" category.
That said as a lightweight alternative when I don't need an IDE I'm very much liking vscode, it's a strange world when my favourite linux editor is made by microsoft.
The only bad part about Jetbrains is that no matter how much i've tried i can't use a text editor without feeling crippled.
A big factor is probably that I started programming using Jetbrains tools (except some c++ in codeblocks before that). It's so awesome everything else just sucks.
The problem is when i want to try some language that is not well supported by IntelliJ. No matter how cool the language is i get frustrated by editors like sublime/atom/emacs.
I know what you mean, I started programming back in the 80's as a kid so I spent about a decade without anything that looks like a modern IDE and since then I've used nothing but IDE's, I can live without an IDE but I seldom want to, it just suits my programming style.
Most importantly I always miss "Go to definition" that usually doesn't work (well?) in editors. Also in javascript. The exploratory power that comes with that is also incredible. I don't need to read your damn docs (unless the module is heavyweight and needs studying), I just want to be sure I called your mehod with the arguments in the correct order ffs!!
> SCode has done the thing that nobody expected MS to do, change the way code was written on Unix/Linux.
...
> I love linux/unix, but the problem always was with the lack of an awesome text editor cum IDE
I mean, its okay if you don't have experience with vim or emacs, but why spew uninformed bullshit when any semi-knowledgeable linux/unix dev knows that vim and emacs run laps around vscode, sublime, etc.
Try building a large webapp in vi and then comment. These days what you do is more important than what you use to do it, use vi or emacs or some shitty text editor, but eventually you need a real IDE with a GUI, vi is great, I love it, but it isn't the thing to be used for a large web app.
>ut why spew uninformed bullshit when any semi-knowledgeable linux/unix dev knows that vim and emacs run laps around vscode, sublime, etc
Because the rest of the entire world doesn't share your opinion.
if you really use vi for a large scale project then salute to you! I am fine with vscode, I want to get things done rather than learn my editor (read spend valuable time learning nooks and corners and the million shorcuts which I'd have rather spent on building my application product or startup)
> Try building a large webapp in vi and then comment.
I've built several using mostly vim as the editor.
> These days what you do is more important than what you use to do it, use vi or emacs or some shitty text editor
I mean that's a cute opinion, but both vim and emacs are much more powerful and flexible than eclipse, intellij, visual studio or other similar crap.
> but it isn't the thing to be used for a large web app.
Why not?
> I am fine with vscode, I want to get things done rather than learn my editor (read spend valuable time learning nooks and corners and the million shorcuts which I'd have rather spent on building my application product or startup)
You probably spend 100x more time making shitposts on HN and other forums than it would take to learn vim and emacs.
>vim and emacs are much more powerful and flexible than eclipse, intellij, visual studio or other similar crap.
Nice claim, now do you have data to back up your claim? Meanwhile let me ask you a few quick questions.
Okay, how do you automatically organise imports in emacs?
Can you jump to the declaration of an expression with just pressing one button? How do you extract functions or values quickly without having to fiddle around with copy paste? If you use a language with type inference can you quickly view the inferred type by pressing a single button?
Yes. There are plugins for all of this. When I was using Emacs, I could use omnisharp to navigate files using, yes, one button. There are refactoring tools for emacs as well, though I'm usually fine with just using multiple cursors (also a plugin) so I haven't tried them out.
All my billable work the last 3 years have been with Emacs (ok, except for the last month, that has been Atom). I have never missed the functionality of an IDE.
VSCode doesn't even change the way code was written on Mac or Windows.
Let me turn the question around. What does VSCode do that Sublime, Atom, Emacs and Vim doesn't? Nothing.
That is not to say that VSCode is bad. It's a decent editor. But the only reason I found Atom and VSCode to be interesting at all, was that way more people know Javascript than ELisp or VimScript, and so I figuere that the quality and quantity of plugins will be better on VSCode or Atom in time compared to the other two editors.
The switch to Atom was actually pretty simple. Many Emacs shortcuts still worked, and setting up a linter and multiple cursors was easy.
Another thing is that there are GUI versions of both Vim and Emacs. You don't, however, have a console version of VSCode, which means you can't use it over SSH. This isn't that big of a deal for some people (maybe even most), but for sysadmins logging in to a server to do some work, access to their editor of choice would be great.
The problem with your statement, and why you receive downvotes, is that you reveal that you really don't know what you're talking about.
>VSCode doesn't even change the way code was written on Mac or Windows.
That's probably because those two platforms have already had superior tools for a long time. On Linux, vim reigns supreme. So it is easier to revolutionize code editing on Linux
All three platforms have had access to Vim, Emacs, LightTable and Sublime. VSCode brings nothing new to the table other than Javascript as a plugin-language.
The fact that you think that VSCode is revolutionary compared to vim, only displays your ignorance. Vim can do the exact same things VSCode can, and it has been able to do so for quite a bit longer.
VS Code is not FOSS, either, I believe? [EDIT: Wait... it is open source. Must have missed that announcement]
I do like it a lot, though. KomodoEdit is pretty neat, as well. Even though it's closer to a full IDE, it feels very responsive. If either VS Code or KomodoEdit added something like paredit, I'd switch to them.
If you're wondering why the downvotes, the great editor war is the reason. I think your comment is valid, but what you could of said which makes the most sense to me is: VSCode has changed the way you yourself code on Unix / Linux as opposed to the way "EVERYONE" codes on Linux, if everyone dropped Vi(m) and Emacs for VSCode then that would speak volumes. I agree with you on Atom, though I've encountered an odd issue with VS Code where it freezes up completely on me, not sure what that's about.
All the responses to this comment seem to center around putting in many, many hours of work to get used to Vim or Emacs. I can't find a single comment about the rejection of Sublime Text because it costs $60. That's the usual complaint against it. To which I say: If you're a professional programmer, how many hours of your time does that come to, for an editor that will make you more productive for years?
As someone who got through engineering school on green screens and vi, I eventually cobbled together a massive collection of Vim plugins... to make it work, essentially like ST, with a side bar, tabs, fuzzy searching, and all of that. Once I discovered ST, I was happy to pay the measly $60 whole dollars for a license which I could run on all 3 desktop platforms, across half a dozen computers.
VSCode magically fits this one narrow set of definitions to reshape the field of coding on Linux and Mac? Are you even serious, or is this just trolling? You're going to let the fact that it's closed source remove it from your list? I obstinately ran Linux on the desktop for 19 years, but I know a good, pragmatic deal when I see it, open source or not.
Isn't this based on Atom (or at least similar design)? It really makes me sad that people are making editors with so many features and nice things, but ignoring the fundamentals like latency.
No, it's not based on Atom. Both VSCode and Atom are built on top of Electron but that's all they share in common. VSCode, unlike Atom, is lightning fast. In particular, it uses a very different rendering and plugin architecture.
Interesting that they decided to release 1.0 before sorting out the coreclr/dotnet story. My understanding is that Mono is still the best way to write C# with VSCode, even on Windows.
It's coming soon. The aspnet team demoed coreclr debugging in VSCode earlier this week. It was all done on nightlys, but it worked.
But honestly, since these are all extensions, I don't see any reason 1.0 would need to be tied to these features.
If you're working on something that needs to target the full framework, then yes, Mono is the way to go. Otherwise if you're targeting the new .NET Core, then you can do without Mono with the latest pre-release versions of the VS Code C# extension (which includes debugging support).
I'm your standard unix greybeard, the sort that uses org-mode to outline-structure their emacs config (that's actually what I do, not even a hypothetical), so I approached VSCode with skepticism.
I have actually been really impressed. It's fast and responsive, even on Linux, and the TypeScript tooling is fantastic. I think with a bit more UI work (like vi keybindings) it could potentially become my preferred editor.
I'm chuckling (not in a bad way!) at the emacs user that prefers vi keybindings expressing optimism about a Microsoft editor written in a statically typed variant of Javascript. Progress is cool.
I try my hardest to not be dogmatic, and my answer to the argument about vi having better keybindings while emacs having better extensibility is "why not both?" :) JavaScript is almost an acceptable lisp, too...
I've seen the vi keybindings complaint a few times in here, and it's my major complaint as well. There are a few plugins, but they just aren't even close to usable in my opinion.
amVim is doing well, and I can attest that its maintainer is both sharp and very humble (in contrast to a lot of what I've seen come out of this nouveau-OSS era that GitHub seems to have ushered in). It's a shame that more people seem to have flocked to the VSCodeVim extension instead. I guess there's something to be said for being the first to grab the "Vim" label to apply to yourself.
Having said all that, many of the unimplemented parts in extensions across the board come down to limitations in the VSCode extension APIs. I've been watching the VSCode team, and they're actually pretty sharp and welcoming, too, so most issues should be ironed out, given enough time. (Although it hasn't been prioritized at this point.)
However, the appropriate unit of measurement to describe how long I've been using Vim is "decades", and through observing (but never seriously using) the attempts to emulate it over the years, I've spent a lot of time thinking about what it would actually take for an app to really support Vim keybindings—aside from actually just being Vim. Unfortunately, even if we assume a team with infinite resources intent on achieving perfection, there are several things about Vim that prove to be irreconcilable with the way almost every interested app is implemented. The only way around this will have to come down to Vim users either collectively participating in some "Great Vim Shift", or just ignoring the remaining gaps entirely and continuing to put up with incomplete emulations.
I switched from Atom to VSCode for Go development on OSX a few weeks ago while Atom's Go plugin was going through a rough few days, and haven't been able to go back.
The patterns of use take a little getting used to coming from Atom or Sublime, but VSCode gives me real static-language IDE features that "just work" simply by installing the Go plugin. Comparable functionality in Atom requires multiple plugins and I never managed to make a few of them work at all. The control+tab file switching quickly became second nature.
I never had the performance issues some people have with Atom (on a 5 year old laptop), but VSCode feels a little quicker at some things. Nothing to write home about.
I love Atom's direction (plugability, a well-cultivated ecosystem, discoverable configuration), but for sheer usability I'm sticking with VSCode for now.
I've been writing OCaml for a while and seeing that VSCode has a pretty sweet integration for F# gets me quite excited. Is there anyone here who's running F# on Linux / OSX and can share their thoughts?
It's amazing, especially with the Ionide (http://ionide.io/) extension. By far the most pleasent F# experience you'll find on ANY platform. I use it on both Windows and OS X and it's been very enjoyable.
The F# support is what got me to try vscode at all. Before that, I was skeptical about all js-based editors (being an emacs guy), but I was pleasantly surprised at how well this vscode+ionide setup works.
Visual Studio is still a bit nicer with regards to handling all the .fsproj stuff, and visually showing you the order of your files, but the editing itself on vscode is definitely on-par with it.
I've tried this route and while the IDE experience is decent, I was not able to get a working Web API in F# using fsharp-generator (yo fsharp). So I used yo aspnet to declare a C# Web Api and tried to reference an F# library generated using yo fsharp. I was eventually able to get the C# project to see the F# project, but intellisense was broken and showed broken references even though the code was able to compile.
It was an uphill slog and I've put it aside for now, but I will keep coming back to it. In the meantime, I feel like I will just have to go to windows and Visual Studio 2015 to get the working experience.
The second sentence in the first paragraph suggests they are actively performing some form of tracking.
> Today, we’re excited to report that more than 500,000 developers actively use VS Code each month.
I've come to expect Microsoft is just going to do that, and it needs to be accepted if you want to use their stuff. Fighting against it is a recipe for a headache. Unfortunately (or fortunately) this editor is great for Typescript and that's my passion.
A competitor should show up in this space and make me even happier.
No. The old way to change it was in product.json - the product configuration, which got rewritten on every update. The new way to do it is in user settings, which don't get modified.
Probably a good option for newbies, but anyone that's been coding for any length of time will already have too much muscle memory to warrant a switch. For me it's Emacs for editing and Visual Studio Pro for "project administration" and in the rare situation, interactive debugging. I've not yet made the leap to OmniSharp, but that's what is next.
I didn't downvote, but you can easily answer your question about what's interesting/exciting about it by simply reading the other comments here. It's pretty clear this scratches the itches of more than a few devs.
I wouldn't call it just an editor, but rather a development tool which is context aware and provides a lot of info about the codebase you're working on, plus helps with the excellent IntelliSense / code completion.
Excerpt:
"For serious coding, developers often need to work with code as more than just text. Visual Studio Code includes built-in support for always-on IntelliSense code completion, richer semantic code understanding and navigation, and code refactoring. VS Code includes enriched built-in support for Node.js development with TypeScript and JavaScript, powered by the same underlying technologies that drive Visual Studio. vS Code includes great tooling for web technologies such as HTML, CSS, Less, Sass, and JSON. VS Code also integrates with package managers, repositories and build tools to perform common tasks to make everyday workflows faster. And VS Code understands Git, and delivers great Git workflows and source diffs integrated with the editor."
It certainly looks from the extension API docs that this is a thing the world needs - a modern GUI shell that allows arbitrarily complex extensions to be written in a language people seem to like. Having looked around the docs as a very heavy emacs user, I am not totally discouraged - every keypress seems to point at a command, and if everything is rendered as HTML, I assume it is effectively infinitely customizable (would love to hear opinions from experienced extension authors). If, on top of that, it solves a lot of emacs' foibles, like threading issues, performance edge-cases etc, then I plan to keep an eye on it.
That said, the available extensions seem pretty bare. I don't see many mentions of REPL interaction, and there are no extensions for many languages. I'm glad it's getting attention, but I suspect it'll take a decade of loving care to bring up to the level of most people's emacs configuration. I see no reason that couldn't happen more quickly, though.
486 comments
[ 2.5 ms ] story [ 127 ms ] threadIs this a jab at Atom? I like this.
So I believe it's a jab at both.
I'll take a look at making something similar.
We built this extension sample to show the capabilities of the extension API - https://github.com/alexandrudima/vscode-vim.
We've done some work to improve the API for the extensions. We'd love your feedback. https://github.com/Microsoft/vscode/issues/3600.
I've thought about doing a vim implementation for years where motions are expressed as composable functions projecting from text range to text range with commands taking a list of text ranges, mostly because I'd like to whether non-text based motions (e.g. AST based or generalized cursors) would work. I like VSCode and expect to move over to it so I've thought about starting my project but the scope of doing a good implementation is daunting.
Congrats on the 1.0 release, VSCode is a great product.
The ideal VIM mode plugin for VS Code would do the same.
It's just too clunky for my taste.
It's also hilarious that Atom gets shat on for data collection when no one cares that VS does it too. Microsoft can do no wrong, only OSS projects have standards to live up to.
FWIW, I can't figure out how to integrate vim into my workflow, since the text editing controls are different than they are in the rest of my OS.
Have you? Or did you read the placeholder document for a version of vim that isn't anywhere near ready for general release? Because if you know where a branch or a build of vim 8 is, I'd appreciate a pointer.
Sorry if I sounded like I was endorsing it. Did you not read my comment?
Can't say much about it, haven't upgraded yet, but the write up on it looks promising.
>completely different product
then call them both
>text editors
emacs and (g)vim have a gui mode.
I'm curious about your answer to this: would you argue that MS should combine Word and VS Code into one text editor?
https://en.wikipedia.org/wiki/Microsoft_Word#Origins_and_gro...
The Internet Archive seems to have a version listed on the 'Abandonware' listings.
https://archive.org/details/msdos_microsoft_word5
Normally I'd be the first jumping on Microsoft products and criticize them but this is a strange statement. Most of what you can find in VSCode runs on nodejs so if you want a specific features in a CLI you don't need VSCode, just install whatever nodejs lib you need and use it from the CLI.
Silverlight, though...
WPF > Silverlight > UWP
All your skills are transferable.
The Future of Visual Studio (https://channel9.msdn.com/Events/Build/2016/B859)
Building Desktop Apps in Visual Studio vNext (https://channel9.msdn.com/Events/Build/2016/B824)
I would like to know what potential gains could come from using a GUI text editor.
I miss things from Emacs sometimes so I keep it around. I miss macros, I miss some of the more stellar Emacs packages (Tuareg for OCaml and Cider for Clojure in particular) but I do a lot of editing nowadays in Atom and Code.
My experience so far is that extensions on VSCode "just work", but they're scarce, and difficult to discover and install.
My experience with extensions on Atom is that they are numerous, cover a very wide variety of needs/wants, and that they frequently break when the main editor updates. I haven't been able to install/update the Omnisharp extension successfully since the npm debacle a few weeks ago.
I dabbled with Spacemacs, and it seems nice, but I couldn't work out how to migrate my existing extensive org-mode customizations without digging deep into the Spacemacs package management system.
What I'm really looking for is something like Atom's Neovim Mode [4], allowing me to use Atom's flexible UI (hey there, CSS) with vim's modal editor, wealth of plugins, and my config (keybindings, etc...).
[0] http://33.media.tumblr.com/1e4bed4a5154bf363e7f24c40eb2177c/...
[1] http://home.aubg.edu/students/PAE120/Brackets/samples/root/G...
[2] http://www.omgubuntu.co.uk/wp-content/uploads/2013/08/adobe-...
[3] https://helpx.adobe.com/creative-cloud/help/extract-for-brac...
[4] https://www.youtube.com/watch?v=FTInd3H7Zec
I'm also pretty comfortable using a mouse--i.e. I don't feel the need to keep my hands on the keyboard at all times--because, when it comes down to it, I spend a lot more time thinking than typing.
I use VS Code when I'm working in one codebase because it has a nice tree view of the files and has a pretty nice "working files" feature where you can easily switch between files you're working on (I usually have five or six files I'm working on at any given time; sometimes in Vim I'll open them all up in a terminal multiplexer and switch between them, but that can end up frying my brain). Seeing the tree structure just helps me visualize the codebase better. VS Code also has a really nice search feature that searches through every file in the folder you have open (I could just grep but it's convenient to click on a result and go straight to the line in that file)
Git integration in VS Code is pretty sweet as well; it has a really nice diff viewer built-in and it's easy enough to add and commit changes (I still use the git cli for branching, rebasing, etc.)
I use Vim whenever I'm in a terminal to edit various files here and there. I feel a little faster in Vim when working on one file, and I do like a lot of the shortcuts/commands a lot better in Vim. Vim also has much better find/replace with regex, and it's a lot easier to extend Vim.
I guess what I'm trying to say is that I don't see VS Code as a full-on replacement for Vim, but a different tool that I use in a different way.
I use byobu as a multiplexer, and I just like it's shortcuts for switching between terminals and tiling etc better than vim's tab shortcuts.
Some reasons:
- Having the full type info for every single thing in the code with simply hovering over it (not just when typing)
- Ability to "peak at definition", to get a little interspersed window with the definition of functions etc, embedded right into your editor.
- Out-of-the box file tree with single click opening, and window management (I use a lot of powerful vim commands, but window management just was too much for my head).
- Maybe something more I've forgot.
In general, the out-of-the box experience is so much greater than vim. I know you can replicate most of the above with a super-fancy setup, but I just don't find the time to get my head around much more than http://github.com/fatih/vim-go and a few personal .vimrc tweaks.
Now as others have mentioned, I just hope for a more feature-complete vim-mode in VSCode.
It might be nice editor, but it hide to much information for my taste. "You need to setup a launch.json file", well fine, but at least be a little more helpful than that, don't just open an empty file. Starting the debugger either crashed the editor or do nothing, but never informs me as to what the issue might be.
At this point Vim and shell is easier to get started with.
Why not both? I use Emacs+evil. I use VS+VsVim. I don't understand why this isn't the preferred mode for everyone? Pick the best environment/shell/whatever, then make sure it uses vim for actual text editing. Problem solved.
Visual Studio Code would be the editor, Omnisharp the Intellisense platform, I think they were also developing some sort of common debugging interface, etc.
It would be a lot nicer than the current Visual Studio setup, where the installation drags in 6GB of cruft.
Of course, this would involve an internal power struggle between Visual Studio Code and Visual Studio proper, and I hope VS Code wins :)
In the C# talk at Build [1], they demonstrated visual debugging using VS code. It was pretty awesome.
[1] https://channel9.msdn.com/Events/Build/2016/B889
I love linux/unix, but the problem always was with the lack of an awesome text editor cum IDE, yep there is eclipse but it is too clunky, I do not like sublime as it isn't FOSS (call me crazy), gedit took way too much memory, geany is fast and mean but the UI sucks plus functionality isn't that great.
Enter VSCode, code writing feels amazing again, not the functional part, but the actual manual part.
I do not like vi because I primarily was learning web dev and I didn't really get my head around using vi effectively and still learn the web dev, so I am not a emacs/vi superstar as I have heard that both of them are fine text editors.
but for the people like me who don't or can't use terminal based editors, VSCode is quite literally the best.
The new Che project of Eclipse does seem promising, but the last time I tried installing it, it took around an hour, consumed GBs of my bandwidth and still nothing.
I am still Waiting for the day I'll be able to program in its entirety on my android device.
I used Atom but it is too slow, it is surprising that VScode and atom share the same ancestor but one is blazingly fast and Atom is so damn slow.
Edit: yep vscode didn't transform coding on unix, it merely changed it to some extent, and why the downvoting? point out where I am wrong, I'll get to learn!
And remember, no one is saying you have to use these programs. Console editors and IDEs will still be here. This is another option for people who want it, which has turned out to be a lot of people.
When my IDE stops working one morning because yesterday's system crash resulted in a plugin being unable to load properly and subsequently peppering me with dialog boxes or worse, crashing the IDE, then it is definitely clunky.
When I just want to do code browsing across 500,000 lines of code and it takes 2-3 seconds every time I hover over a symbol just to populate the object list, that is slow.
Your experience sounds great. My experience has been that every IDE configuration falls into rot after 6 months to a year or so and the whole thing needs to be deleted and reinstalled. That's also slow.
Meanwhile, vim+ctags+gdb have given me years of reliable service. More than once I've had an IDE collapse into a pile of errors and turned to my trusty basic tools, only to leave the IDE as the steaming mess that it turned into for weeks or even months as I just didn't need that browsing or inline debugging power at the time.
Emacs has functioned as an "advanced text editor" for at least 20 years and probably longer. There's a very common misconception that Emacs is a "console editor", but the reality is that when you first launch it in a windowed environment you get something that looks an awful lot like Sublime, VSCode & Atom: a text editor window with a menubar and toolbar similar (yes, it's not perfect!) to what you'd expect from any other editor native to your chosen platform.
The time investment involved in learning how to use it is also considerably less than implied elsewhere in this thread. In fact I really doubt that it's significantly more than you'd have to spend educating yourself about any other "advanced editor"'s configuration, keybindings for non-obvious actions, extension mechanism, etc. It's easy enough to learn the (admittedly unconventional) keybindings for a handful of common things like opening and saving files when you have the menus to refer to, and by default it'll even open a buffer containing clickable hyperlinks to helpful things like tutorials. I still haven't seen an editor or IDE with better built-in help.
Even configuring Emacs isn't all that hard: there's a built-in interface for installing packages, most of which will pretty-much auto-activate once installed (i.e. less need to mess around with elisp), and for changing configuration there's "customize", which is a nicer way to change configuration variables than just editing a JSON file. When you do have to start writing some elisp code (you'll almost certainly have to write a little) the documentation is superb and there are more than enough resources on the web to help you. A programmer who is already familiar with a dynamic language like JS will probably have less trouble learning elisp than a C programmer did 20 years ago.
None of which is to say that there aren't areas where Emacs isn't behind. I'd like to see better support for projects, snippets and auto-completion out of the box, as well as being more nicely pre-configured for popular languages like JavaScript and Python. Emacs 24 is four years old at this point, and that's a very long time for any developer tool to stay still.
These days I'd say the most confusing thing about Emacs is working out which of the many competing packages you should choose for whatever it is you're trying to do. Age is working against it here, because what was the almost-universally-recommended package five years ago - for which you'll get plenty of helpful google search results - has often been superceded by something better.
But with a handful of plugins installed (yasnippet, helm, projectile, auto-complete) it's (IMO of course) still the best editor out there.
I'll be an Emacs user for life, but I am currently recommending Atom to people wanting to move away from language-specific IDEs and dabble in a text editor, because it has enough of the Emacs nature while not being too daunting.
I've noticed this happen especially on big projects/files.
Also, sometimes the auto complete popup is very slow to appear and causes lag.
I don't use many GUI text editors and have not compared VS to Atom/sublime, but for me this is just unacceptable.
I'm a heavy IDE and Emacs guy though, so perhaps I'm missing something.
Light Table might deserve the term "transformative", but I didn't find it usable enough to rely on.
Nope. Visual Studio Code was created before Atom.[1] Although both VS Code and Atom are based on Electron[1] and are both Chrome-based. VS Code does seem to be stealing Atom's thunder as what they say [1]
[1] https://discuss.atom.io/t/atom-seems-to-be-lossing-contribut...
The source you cited even says this!
https://discuss.atom.io/t/atom-seems-to-be-lossing-contribut...
Atom = 2014
https://en.wikipedia.org/wiki/Visual_Studio_Code
VSCode = 2015
Am I missing something? Sure, MS had some preview online IDE thing before VSCode came out, but that's not the same thing obviously.
Visual Studio code was originated from "Monaco" team, dated back in 2013.
Eletron (formally Atom-shell) was dated in Feb-March 2014.[3]
[1] http://code.visualstudio.com/blogs/2016/04/14/vscode-1.0
[2] http://arstechnica.com/information-technology/2015/04/micros...
[3] https://en.wikipedia.org/wiki/Electron_(software_framework)
That makes sense. I use things from the future all the time. /s
Also: Doesn't ask me to save my unsaved files when I close the editor. Sublime Text called this feature "hotexit", but in Atom there's no way to disable it.
Vim and Emacs are still superior if you want to put the time in, and both have non-terminal interfaces. They can also be both customized to be whatever you want them to be, there's not really a limit to their functionality except what plugins are already written. Ditto for Atom, though of course, it does seem to be more web based for the moment (though Atom does have great plugins for Go, Nim, and I'm sure a bunch of other languages).
In the grand scheme of things, tools like compilers, debuggers, interpreters, other command line tools (like completion servers), etc..., matter more than editors anyway.
Edit - for the record, VS Code seems great. But it's not revolutionary.
That is the power of vscode, it provided a good enough way to play with code, yes not outright innovation, but an awesome text editor nonetheless.
I'm not saying Vim and Emacs are the be-all (I program mostly in R, so RStudio is my main tool), only that VS Code hasn't changed anything fundamentally. It's just a good editor.
Or, hell, even Kate?
Of course you can do a lot with extensions, but at least in Atom's case they break a lot for me.
Bear in mind that the claim wasn't that it's better in some ways, but that it's sweepingly better than the stuff that came before (and Atom wasn't even mentioned by the OP, which is funny--I mean, I don't use it, but it's obviously in the conversation).
Uh, if you edit tens or hundreds of text files per day, it's a game changer.
I guess the killer feature of VS Code is multiple cursors (Ctrl+D). I only know of Sublime Text and Atom who also have this feature on Linux, not sure about Kate. Sublime Text is closed source and not gratis, Atom is slow and buggy.
No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.
That they are not built-in really doesn't matter though. All these editors revolve around plugins, and it's common practice to save your preferences on github or the like so that it's easy to use the same settings and plugins on every machine.
I think you have to wait a few minutes, then it gets activated.
> No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.
That's too complicated for me. Last time I've tried to set up vim and emacs to my liking it was a mess: A lot of copying and pasting around random code, changing configuration files I didn't understand, ...
Granted, Atom, Sublime, VSCode etc. are easier to start with because they expose customization through JSON files instead of a custom programming language. But if someone where to tell you that they didn't understand how multiple cursors worked in VSCode, you would tell them to learn their tools and send them a link to the relevant page of the documentation (if that).
If you know your editor, adding functionality like multiple cursors is easy. The greatest strengths of extensible lightweight editors like VSCode and Emacs, is that such functionality is only a package away.
No that's the thing: I would tell them to press Ctrl+D, simple as that. Multiple cursors in Sublime Text, Atom and VSCode are intuitive and it's the first time in an editor that I actually use them.
EDIT: that's only the most trivial benefit of git integration
I want to keep on top of my current branch, what is untracked, what is unstaged and staged, quick diffing, etc. It actually helps a lot with productivity since I don't have to actively query for this information when it's all in one screen.
If I used another editor, I would like to have similar features. Maybe it can be done, but I am quite fluent in magit already, and one major thing keeping me from moving to another text editor for my current projects (if it actually mattered.)
The only 'plugins' I use are a keyboard shortcut (cmd+space) which puts me in a terminal window and rupa/z[1] for jumping into a project directory.
[1] https://github.com/rupa/z
Another scenario: You type `git status` and see a file called `src/a/very/long/path/file.c` hasn't been staged yet. Now you need to type that file path for git add or git diff. Takes more than 5 seconds, but it's just a simple click on a + symbol in VS Code.
vscode's benifits:
blazingly fast modern design works on linux/mac too little features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there.
It is a great way to code if you don't want or can't use vi/emacs, I don't have the luxury to learn all the nook and corners of emacs, I started using Go plugin in vscode and today I have built go apps and written partially completed book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook...
i tried giving vi a chance, but nope. couldn't bear it for more than a day, large webapps require a UI IDE, vscode > everything else I tried till now
Literally every other popular code editor supports some form of "go to symbol".
Go ahead and downvote it, but after all every programmer worth his/her salt does realize that the choice of IDE/text editor is ultimately a personal opinion, so long as you as a person are comfortable using it, that is good for you, it does not make a tad bit of difference to anyone else in the world.
IntelliJ
TBH, not every developer is willing to become a power user or interested to learn an IDE instead of the language itself. Being someone who worked on VStudio alot and now on Linux/Mac based tools, I can safely say that Microsoft tools are Developers friendly most of the time. It's good they are introducing same touch for Linux/OSX community.
Very few programming workflows are so complicated that it is simply not possible to do something without first creating your own highly customized environment within Emacs. However, very, very many programmers do have a lot more fun screwing around with customizing their work environment (editor, window manager, shell, etc.) than using that environment to get actual work done (myself included).
Which is not to say that Vim and Emacs aren't awesome tools, I just wouldn't generalize anything about anyone based on the tools they use.
For example, do productive programmers tend to use Vim or is it the other way around? It's hard to find the causality.
Nerdvana.
Humans have this funny thing as they grow older - they look at a thing, maybe try it out for few seconds, and then immediately determine it's too difficult and it will take forever. They rarely bother to spend actual five minutes, to the clock. If they did, they might actually have learned something.
25 minutes of deliberate practice - a single Pomodoro - is enough to become acquainted with several of Emacs features - like, navigation by semantic units and incremental search and autocompletion. You won't get proficient in that time, but it's enough to rewire yourself to actually start using it when writing code. Which will then lead to you becoming proficient while doing your regular, billable work.
Seriously, set up a Pomodoro timer, sit in front of Vim or Emacs, and try to practice a few things. You'll be surprised how fast you can learn.
(And yes, I did that, so I'm not talking out of my ass. I actually almost doubled my Emacs productivity once in 5 pomodoros - in 2.5 hours - two of which I spent watching Emacs Rocks videos, two on rewriting s-expressions with Paredit, and one on multiple-cursors.)
To reach a level of skill where using emacs is easier/faster/better than something like intelli-j (for instance) requires significant dedication and repetition.
Far, far more than "a few hours".
Not parent but I have. I still would recommend something else for all the stuff I work with.
That said, it is amazing, I just believe in my line of work people are better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.
I sometimes do to. In particular, when that stuff is Java or C# - it's hard to beat the support IDEs gives you there. So I personally opt to switching said IDEs to Emacs keybindings instead.
(Also, one could argue that you need IDEs there mostly as crutches to support the weak language, but that's a topic for another day...)
> better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.
Refactoring - if you mean semantic transformations supported by your IDE, then yes. See above. But for search/replace and block selection no IDE beats the convenience of Vim and Emacs. They simply can do that better and more naturally (along with plethora of similar things helping with selection and navigation). And this is exactly the type of thing I was talking about in my previous comments - you can learn both under one Pomodoro if you focus solely on it, and then normal work will quickly take you to proficiency.
Not the parent, but I've spent a significant amount of time with pure vim. I use vim bindings in everything from my web browser (vimium, vimperator) to my WM (i3 & kde vim navigation bindings), to my text editors & IDEs (atom, VS, sublime)
Despite all that, I still find using pure vim to be ineffective relative to just using Atom, Sublime, VS or whatever with vim bindings. I may have internalized the most basic navigational concepts, but the more advanced / esoteric shortcuts that are essential to use vim as an exclusive editor are still ones I need to look up - and that's not counting stuff specific to vim packages liked nerdtree.
At the end of the day I'm sure you could always argue that I should have practiced differently / better / more or whatever - but to what end? There are plenty of full featured text editors on all platforms that do everything I need. Why on earth should anyone force themselves through dedicated practice just to learn the intricacies of a 20 year old editor?
I was thinking more of the sorts of automatic refactoring tools some people really like to use in their IDEs. I haven't found that such tools save enough time to be worth learning how to use them.
I really don't think that's what's behind my attitude toward code editors, though. I've been writing code for thirty-odd years and making a living at it for twenty-five, and I've spent the majority of that time working on dev tools. Compilers, mostly - but I've written a couple of editors, too, plus a debugger, a couple of linkers, an assembler, you name it. So I have had a lot of time to think about tools, and have been lucky enough to get several chances to put my ideas into practice.
I'd have trouble remembering the names of all the different editors and IDEs I've used over the years. Emacs and vi are ubiquitous now but that was certainly not always true, and on some platforms, particularly embedded environments, using anything but the officially-blessed toolchain can make your life unnecessarily difficult. I have learned to get my work done using whatever tools happen to be on hand. That's meant a wide variation in the kinds of features which are available, the specific control-key bindings, the details of the build environment, pretty much anything you can imagine - so I have learned to rely on the basics and ignore the rest.
I find it far more frustrating to deal with a sophisticated tool that isn't working quite right than a simple, brainless tool that does the job but requires a little extra manual labor.
I'm not here to play with editors, after all, I'm here to build software, and the editors are just a means to that end. Time spent learning sophisticated editor features has to justify itself in time reliably saved using those features, which has to be balanced against the time wasted when they don't work quite right or when you have to go dig through the documentation to remember how to use them, times some distraction multiplier for the fact that you're thinking about the tool instead of the job you're using the tool to do. In my experience, there's been too much change and not enough actual need for sophisticated editor features to justify their cost.
Even if a sophisticated editor could allow me to perform certain editing tasks more quickly, that wouldn't change my overall productivity very much at all, because I spend far more time reading and thinking than I spend typing or editing. I type fast enough already; it's my brain that needs to be accelerated, and the best way I've found to do that is to eliminate distractions and focus as much as possible on the problem I am actually trying to solve.
I wrote a simple terminal-based editor a couple of years ago, including all the features I use every day and none that I don't, and I've been using it for all my daily programming work ever since. It's an unabashedly personal expression of my own taste, so I wouldn't necessarily recommend it to anyone else, but I like it and feel good when I use it. It's nice to know everything there is to know about the tool, so that I never have to think about it or try to remember how it works. Perhaps some day I'll be working in some new environment with some new toolchain and I won't be able to take ozette[1] along with me, but that's fine - wherever I go, I'll be able to get my work done with the tools I find there, because I'm comfortable doing my job with the basics.
1 - http://www.github.com/marssaxman/ozette/
verbs like ci" (change inside ") which deletes inside the current double quotes and leaves you in insert mode are pretty easy to get used to. dd deletes a line and puts it into the yank register so you can paste it somewhere. u undos an action.
using a plugin with visual studio is pretty king to get the best of the IDE and the most common vim functionality.
Classic SO answer on why vi: http://stackoverflow.com/a/1220118/1772636
edit: here is another classic why vi answer that is a bit different http://www.viemu.com/a-why-vi-vim.html
You only think that because you have used it and became accustomed to vstudio. As someone who has used vstudio, eclipse, atom, intellij, vim, emacs - I can safely say that vim and emacs are far more 'developer-friendly' than the others.
The sole concept of IDEs specialized for one language makes me cringe.
Can you explain this a bit? I don't see that Sublime, VS Code, Atom, etc. were made for one language, at all. As a little background, I've used vim for a while, then switched to Sublime Text, and am just trying VS Code. I find Sublime/VS Code/Atom to be far easier to customize than vim.
I was indeed referring to Eclipse and Visual Studio. From what I observed around me, for some reason, people don't use these to edit:
- shellscripts/perlscripts/batchfiles.
- Files written in a in-house domain-specific language.
- Configuration files.
- Makefiles and project files: vcxproj, sln ...
Actually, I observed that these kind of IDEs discouraged people doing the above things, giving them the impression that it's not "real development" (I suspect that this is, in part, where the bizarre term "scripting language" comes from, but this is another debate).
I still use Vim a lot, for JavaScript, for text, for remote sessions... But when a tool with real semantic highlighting and understanding of code is available (with a Vim plugin) then I'll take that.
Of course an IDE like QT Creator does many things better. But it's a tradeoff always.
And that doesn't solve the problem of having one file compiled with different flags, which happens frequently.
And it won't do completion in headers because those aren't actually compiled.
It all really comes down to Vim not having the concept of workspaces and projects - Vim only views files as the filesystem sees them, rather than as your build tools see them. That, to me, is Vim's greatest failing and biggest source of gripes.
You will see that after you learn how to use Vim you won't want to use anything else to edit text, you emails, browser and word processing will be in Vim.
I am not aware if that feature is available in other editors, I tried light table for a short time, but it isn't getting much attention since they are working on some other product. ctrl +P transformed the way i write go code, now I dont' have to bother to remember which file stored what, just ctrl +P function name, as i know what all functions I am using or I can just scroll!
VSCode and Atom are essentially just Sublime Text with Javascript instead of Python as the plugin language. Also, IntelliJ has had this for quite some time, though it doesn't meet the criteria for light weight text editor, it is certainly better than Eclipse.
I don't need an instruction manual to figure out how to close VSCode.
> I don't need an instruction manual to figure out how to close VSCode.
To close GVim, you click the 'x' in the upper right/left corner, like any other window.
Alternatively, you could just close the terminal window.
Oh but that's needlessly hard and annoying? Well so are Vim and Emacs.
I do, however, agree with you. Mostly because you can customize Atom and VSCode to have all the same benefits as Emacs and Vim. Except for running them in the console, which I know some people like having the option of doing.
I think the parent was talking about modern text editors such as Sublime, Atom, Brackets etc.; Vim and Emacs are completely different beasts (note: I love both).
Within the category of modern text editors, VS Code is in my opinion revolutionary in several ways - I will give you three examples
The first feature that I find "disruptive" is the way VS Code offers a standardised interface for debuggers, hence debugger plugins are much easier to create - and you can see that VS Code already has debugger plugins available for many languages: https://marketplace.visualstudio.com/vscode/Debuggers?sortBy... the availability of such plugins for Atom and Sublime Text is not nearly as good.
The second aspect where VS Code changed the game is the clever way it leverages Electron (the framework it's made with, Atom is made with Electron too) - while creating clever workarounds to known Electron bugs - e.g. VS Code, unlike Atom, does not suffer from this bug https://github.com/atom/atom/issues/10720
The third aspect is the git integration - since Atom is sponsored by Github, you would think it has the best git integration out there - but VS Code has gone the extra mile by giving you a great user-friendly UI interface for staging and committing (yeah, I know, anything more complicated than git add -A requires the command line - the fact is that nearly 50% of all the git commands I type are git add -A, LOL).
PPS I totally agree with you about the importance of tooling. But e.g. if you have a debugger that does not have an interface to your editor it becomes hard to set breakpoints. So the editor needs to integrate with your tools and VS Code is great at that.
I still use emacs for quick editing, moderately complex search-and-replace in limited numbers of files (for when I don't want to bother with perl), and a handy scratchpad for throwaway things, but I don't intend to do a lot more software development in it anymore.
I like being able to use other languages for editor extension, having a competent graphical and text layout layer with image support, and quite frankly I find emacs development tedious now.
So... Do I need a few more years of time to "get it?"
I prefer Intellij so much I use CLion instead of Xcode on OS X and Visual Studio on Windows 10.
I can build .exe's that run fine on Windows this way and executables that run on OS X (using the X-Code supplied compiler and build tools that CLion depends on for OS X). I can get qt, wxWidgets and GLFW UIs working for both platforms from the same code base with CLion.
Atom & IntelliJ?
"gedit took too much memory" - what? It eats like 5-10Mb...
I mean, what is going on, why people tend to blow VSCode out of the water about how good it is!? I mean, ok it is cool, has some really nifty features I would like to have in some X editor, but no way in hell it is as game-changing as people state. And I really can't see my self switching from Vim to VSCode. Even when I decide to use GUI Editor (I am not HC vim user, for some environments I use it, for others I don't), it is Sublime. I ditched Sublime for Atom since December, and on OS X, it is working very well. Not blazingly fast and smooth as Sublime, but it is far far better than before.
But all in all I am not biting that Electron base for text editor. I mean ok, JS is cool, web is the future, flexible cross-platform solutions are the thing, but it still isn't comparable to native stuff. At least to me, it is getting there year by year but still a long way to go.
For my personal project (which is in Rust) I use Atom, which is new for me, but I find to be really impressive. Both its plugin system (which allow for all the extensibility and in my case Rust support) is fantastic, and I don't know where the complaints about speed come from (it's far lighter than IntelliJ, obviously).
I've really been enjoying Atom when I do use it, and don't see why I'd switch to VSCode unless it had better support for Rust. But perhaps I'm missing something.
I am a bit turned off by VSCode, it's workflow by the looks of it feel strange to me. Yes I've tried it, yes it was in beta, but right now I am having only Vim on my Mac. Uninstalled Atom this morning, got a little bit frustrated.
It just feels like a web app, I mean it basically is. And when I dragged it to AppCleaner, it is so heavy, 260MB+.
I want GitHub to stream line it. If other were able (look at VSCode for example) that GitHub can. That things leaks memory very now and then. Sublime feels rock solid and blazingly fast compared to Atom, and there you see the difference between native and web. Those fractions of seconds are important when you have app like text editor, especially if used by developers and geeks. :)
Can you elaborate?
It is a great replacement for notepad, but that's what it is. wrong tool otherwise for a large project.
Sure, if you find fault with and don't use the 14 other options, the one you're left is, quite literally, the best.
I usually try to keep my source files and config files smaller than a few hundred megabytes. Sounds like you might need more specialized tools for your unusual approach to editing source code.
Didn't ever understand people who used it for the things Notepad++ could do back then though.
I realize that's a pretty harsh statement but that really sounds like the worst possible way to go around writing code.
I understand that VSCode has changed coding for you. But how has it changed anything for the 92.8%[0] of developers that don't use VSCode?
[0] http://stackoverflow.com/research/developer-survey-2016#tech...
I haven't loved working with a tool so much since Delphi 6, it has plugins for everything I want to do, they work really well, I can have a project open and use multiple languages seamlessly, it's extremely customisable.
It's right up there with Linux in my "tools I wouldn't want to live without" category.
That said as a lightweight alternative when I don't need an IDE I'm very much liking vscode, it's a strange world when my favourite linux editor is made by microsoft.
A big factor is probably that I started programming using Jetbrains tools (except some c++ in codeblocks before that). It's so awesome everything else just sucks.
The problem is when i want to try some language that is not well supported by IntelliJ. No matter how cool the language is i get frustrated by editors like sublime/atom/emacs.
So instead you decided to use an electron based editor?
Don't get me wrong, Atom and VSCode are both great. But "memory efficient" is not a word I'd use to describe either.
...
> I love linux/unix, but the problem always was with the lack of an awesome text editor cum IDE
I mean, its okay if you don't have experience with vim or emacs, but why spew uninformed bullshit when any semi-knowledgeable linux/unix dev knows that vim and emacs run laps around vscode, sublime, etc.
>ut why spew uninformed bullshit when any semi-knowledgeable linux/unix dev knows that vim and emacs run laps around vscode, sublime, etc Because the rest of the entire world doesn't share your opinion.
if you really use vi for a large scale project then salute to you! I am fine with vscode, I want to get things done rather than learn my editor (read spend valuable time learning nooks and corners and the million shorcuts which I'd have rather spent on building my application product or startup)
I even wrote a short tutorial about writing webapps in golang: http://github.com/thewhitetulip/web-dev-golang-anti-textbook...
all thanks to vscode + go plugin
I've built several using mostly vim as the editor.
> These days what you do is more important than what you use to do it, use vi or emacs or some shitty text editor
I mean that's a cute opinion, but both vim and emacs are much more powerful and flexible than eclipse, intellij, visual studio or other similar crap.
> but it isn't the thing to be used for a large web app.
Why not?
> I am fine with vscode, I want to get things done rather than learn my editor (read spend valuable time learning nooks and corners and the million shorcuts which I'd have rather spent on building my application product or startup)
You probably spend 100x more time making shitposts on HN and other forums than it would take to learn vim and emacs.
Nice claim, now do you have data to back up your claim? Meanwhile let me ask you a few quick questions.
Okay, how do you automatically organise imports in emacs? Can you jump to the declaration of an expression with just pressing one button? How do you extract functions or values quickly without having to fiddle around with copy paste? If you use a language with type inference can you quickly view the inferred type by pressing a single button?
All my billable work the last 3 years have been with Emacs (ok, except for the last month, that has been Atom). I have never missed the functionality of an IDE.
https://news.ycombinator.com/newsguidelines.html
Honestly you sound very misinformed. Vim is capable of pretty much everything that VS code is capable of and then some.
Let me turn the question around. What does VSCode do that Sublime, Atom, Emacs and Vim doesn't? Nothing.
That is not to say that VSCode is bad. It's a decent editor. But the only reason I found Atom and VSCode to be interesting at all, was that way more people know Javascript than ELisp or VimScript, and so I figuere that the quality and quantity of plugins will be better on VSCode or Atom in time compared to the other two editors.
The switch to Atom was actually pretty simple. Many Emacs shortcuts still worked, and setting up a linter and multiple cursors was easy.
Another thing is that there are GUI versions of both Vim and Emacs. You don't, however, have a console version of VSCode, which means you can't use it over SSH. This isn't that big of a deal for some people (maybe even most), but for sysadmins logging in to a server to do some work, access to their editor of choice would be great.
The problem with your statement, and why you receive downvotes, is that you reveal that you really don't know what you're talking about.
That's probably because those two platforms have already had superior tools for a long time. On Linux, vim reigns supreme. So it is easier to revolutionize code editing on Linux
The fact that you think that VSCode is revolutionary compared to vim, only displays your ignorance. Vim can do the exact same things VSCode can, and it has been able to do so for quite a bit longer.
VS Code is not FOSS, either, I believe? [EDIT: Wait... it is open source. Must have missed that announcement]
I do like it a lot, though. KomodoEdit is pretty neat, as well. Even though it's closer to a full IDE, it feels very responsive. If either VS Code or KomodoEdit added something like paredit, I'd switch to them.
As someone who got through engineering school on green screens and vi, I eventually cobbled together a massive collection of Vim plugins... to make it work, essentially like ST, with a side bar, tabs, fuzzy searching, and all of that. Once I discovered ST, I was happy to pay the measly $60 whole dollars for a license which I could run on all 3 desktop platforms, across half a dozen computers.
VSCode magically fits this one narrow set of definitions to reshape the field of coding on Linux and Mac? Are you even serious, or is this just trolling? You're going to let the fact that it's closed source remove it from your list? I obstinately ran Linux on the desktop for 19 years, but I know a good, pragmatic deal when I see it, open source or not.
https://pavelfatin.com/typing-with-pleasure/
I'm eagerly awaiting a mac version of 4coder (http://www.4coder.net/).
Here's a blog post with bit more info on setting up VS Code with the pre-release version of the C# extension (and debugging support): http://www.tattoocoder.com/setting-up-asp-net-core-debugging...
I have actually been really impressed. It's fast and responsive, even on Linux, and the TypeScript tooling is fantastic. I think with a bit more UI work (like vi keybindings) it could potentially become my preferred editor.
Having said all that, many of the unimplemented parts in extensions across the board come down to limitations in the VSCode extension APIs. I've been watching the VSCode team, and they're actually pretty sharp and welcoming, too, so most issues should be ironed out, given enough time. (Although it hasn't been prioritized at this point.)
However, the appropriate unit of measurement to describe how long I've been using Vim is "decades", and through observing (but never seriously using) the attempts to emulate it over the years, I've spent a lot of time thinking about what it would actually take for an app to really support Vim keybindings—aside from actually just being Vim. Unfortunately, even if we assume a team with infinite resources intent on achieving perfection, there are several things about Vim that prove to be irreconcilable with the way almost every interested app is implemented. The only way around this will have to come down to Vim users either collectively participating in some "Great Vim Shift", or just ignoring the remaining gaps entirely and continuing to put up with incomplete emulations.
The patterns of use take a little getting used to coming from Atom or Sublime, but VSCode gives me real static-language IDE features that "just work" simply by installing the Go plugin. Comparable functionality in Atom requires multiple plugins and I never managed to make a few of them work at all. The control+tab file switching quickly became second nature.
I never had the performance issues some people have with Atom (on a 5 year old laptop), but VSCode feels a little quicker at some things. Nothing to write home about.
I love Atom's direction (plugability, a well-cultivated ecosystem, discoverable configuration), but for sheer usability I'm sticking with VSCode for now.
It just works. The workflow is fine for me, git integration is a plus. Compared to Atom, I don't need to try plugins to get descent functionality.
Actually, it's the first MS product I use in like... 10 years?
I used to be an emacs fan, I used to be an Eclipse plugin developer, I used to be a WebStorm user... now I prefer VSCode.
I love how it makes the best of screen real estate compared to WebStorm
https://github.com/Microsoft/vscode/issues/3790
Visual Studio is still a bit nicer with regards to handling all the .fsproj stuff, and visually showing you the order of your files, but the editing itself on vscode is definitely on-par with it.
It was an uphill slog and I've put it aside for now, but I will keep coming back to it. In the meantime, I feel like I will just have to go to windows and Visual Studio 2015 to get the working experience.
"telemetry.enableTelemetry": false
> Today, we’re excited to report that more than 500,000 developers actively use VS Code each month.
I've come to expect Microsoft is just going to do that, and it needs to be accepted if you want to use their stuff. Fighting against it is a recipe for a headache. Unfortunately (or fortunately) this editor is great for Typescript and that's my passion.
A competitor should show up in this space and make me even happier.
You should take a closer look at it's features.
Excerpt: "For serious coding, developers often need to work with code as more than just text. Visual Studio Code includes built-in support for always-on IntelliSense code completion, richer semantic code understanding and navigation, and code refactoring. VS Code includes enriched built-in support for Node.js development with TypeScript and JavaScript, powered by the same underlying technologies that drive Visual Studio. vS Code includes great tooling for web technologies such as HTML, CSS, Less, Sass, and JSON. VS Code also integrates with package managers, repositories and build tools to perform common tasks to make everyday workflows faster. And VS Code understands Git, and delivers great Git workflows and source diffs integrated with the editor."
That said, the available extensions seem pretty bare. I don't see many mentions of REPL interaction, and there are no extensions for many languages. I'm glad it's getting attention, but I suspect it'll take a decade of loving care to bring up to the level of most people's emacs configuration. I see no reason that couldn't happen more quickly, though.