VSCode knockouts Atom in a dispute for becoming a developer editor in a corporate computer.
Sure, you all have root password in your computer. Unfortunately, I belong to a lower race: the corporate developer. I work in a Windows 7 machine, don't have root password and there's a big wall called proxy around me.
I didn't know about VSCode before this HN post, but I was trying to use a new editor instead of Notepad++. In my 5 minutes comparison match between Atom and VSCode, Atom was knocked out in the first minute. To quickly test a new general code editor I just want 3 "simple" things: column selection, regexp search and replace, and a python mode.
Atom: got the regex, must install a column mode extension, need to install a ntlm proxy authentication downloaded from (argh!) Sourceforge, configured it after some google searches, failed to install the extension because it needs a compiler. Ops, just spent 30 min for my 5 min test. Can't spend more time playing with a code editor, must go back to work.
Just wanted to say I find Notepad++ to be an excellent tabbed editor, especially for XML or SQL. I use it on windows all the time and really miss it on OS X where I find Textmate to be a bit awkward.
I've been a long-time fan of Notepad++, but it's a text editor. You can extend it to make it work better with specific programming languages (e.g. here's a post I wrote 10 years ago about adding language support http://weblogs.asp.net/jongalloway/creating-a-user-defined-l...) but it's fundamentally a text editor.
VS Code is a code editor. It has IntelliSense (not text-matched autocomplete, IntelliSense), debugging support, git integration, parameter hints, go to definition, code peek, etc. (http://code.visualstudio.com/docs/editor/editingevolved). The goal is to give you code editing features with the speed and simplicity of a text editor.
They're both free and lightweight, so I use them both pretty much daily.
Notepad++ is very useful but I wish some features would be updated. The dialogs are awkward to use at times. The XML for defining custom syntax highlighting is atrocious. It's like they took a pre-XML config file and shotgunned tags into it without planning a rational format. Keywords are specified using long strings delimited by CR/LF entities for no good reason other than to destroy readability. It would be nice if an more modern hightlighting engine could be inserted as an alternative to the clunky ad-hoc design it currently has.
As you say, both are useful for different things. They complement each other if you use the right tool for the right job.
I find Notepad++ is great for handling really large files and changing UTF encoding or line endings. VS is good for pretty print formatting code/XML to be more readable, among many other non-text things such as debugging.
I don't need to do this often but occasionally you'll need to fix inconsistent line endings, change encoding to UTF-8 or remove a BOM [0] (to stop  being prefixed by some old software).
In OS X and Linux (and Windows with Cygwin etc) there are several command line programs such as unix2dos (line ending conversion), iconv (encoding conversions) etc for doing just that, so that you don't need to do it in an editor and can even automate the work.
Coming from OS X, there are a bunch of minor things missing in Notepad++ that I'm used to having on OS X. Like the ability to drag tabs between windows with the mouse, to move new tabs to a new window, or to create a new file and immediately save it. The scrolling in Notepad++ is also a little buggy. Just to give you a perspective about what the other side thinks, since you inevitably develop different habits in different editors, and those habits break when you switch.
That said, I use too many editors for my own good. (I'm active in both main churches.) Neither Notepad++ nor TextMate are competitive with VS Code, Emacs, or Vim, IMO, and I use all five regularly.
> On the contrary we have mostly consistent ctrl/shift + arrow behavior
Are you saying Windows has consistent Control/Shift + arrow behavior?
OS X is pretty consistent about this too, though Control+Arrow moves between Desktop Spaces, not related to text, but you can modify a lot of system/app shortcuts from Preferences -> Keyboard -> Shortcuts.
Notepad++ is a great text editor, but it has no clue about your code base. It can't do searches of all functions, or Ctrl+Click on the method to go to its definition, etc.
I love ST, but the hotkeys are so different between Windows and Mac and it drives me up the wall. I feel like I'm abroad in the UK and now fries are chips, chips are crisps, crackers are biscuits, Ctrl+H is Cmd+Shift+F, etc... It really gets in the way of my ability to work in my editor fluently, which is ultimately all a text editor is good for.
And the best feature of TextWrangler: if it crashes, or the computer shuts down, it remembers unsaved changes in files. Start it up and it restores everything to the last keystroke.
I'm always surprised that PSPad [1] doesn't get mentioned much in these conversations. I find the built-in utilities are more numerous and work much better than Notepad++. It also handles large files much better IME.
It may be that the customisation is a bit less polished (eg, no way to quickly set themes) and the user community is less developed. But it really does everything and much better than the others IMHO.
Seriously try gvim. Not vim where you need a long ass cheat sheet just to create a new tab or move between splits. But gvim where you can be productive and use the mouse and menus when necessary.
I want to type :wa in one window, not four windows. I don't want to get an error message when I try to open a buffer that's already open somewhere else, I want it to just move the buffer to the new window (or alternatively, raise the window containing the buffer). I want to move buffers across windows and keep undo history and register contents. TextMate / Emacs / etc. have this capability, but I can't figure out how to do it in vim.
How do corporate developers test and debug things without the root password? In some cases, you need to be able to start Visual Studio in UAC mode, and debug an already running process...
From a security perspective, we ask: why are you developing applications that can't be ran by normal users?
For the 1% of devs working on system level stuff we provide VMs or separate physical servers that aren't joined to the corporate domain and don't have sensitive information on them.
As an example, VS needs UAC permission to integrate with a local IIS install, so there's a big group of .NET-based web developers that really need it with such a setup.
But honestly, giving a developer non-admin privileges of their own (as in their work environment) computer is like giving a carpenter a rubber hammer to hammer nails. I find it insulting.
At a lot of workplaces (like mine) it goes beyond that - developers aren't allowed to install software even under their own user account, where admin privs aren't needed.
Consider the irony of that, when one of the approved pieces of software is a compiler. We can make our own programs, hello!?
> From a security perspective, we ask: why are you developing applications that can't be ran by normal users?
Really? This question from a security engineer on Hacker News? I can tell you've never developed on Windows because (as pointed out) Visual Studio needs root level permissions to operate. The level of access a user needs to run my program has nothing to do with the level of access I need to build the program. They are completely disjoint.
I'm sorry but you are incorrect. VS needs admin rights to install into Program Files, registry updates and GAC install, etc. Otherwise the apps a developer builds are run in in their own process and unless there are special circumstances, should not need admin privs; VS should never be run as admin apart from those special circumstances.
What about tools like Docker or VirtualBox? Every time those high-frequency release software are updated, you need to request sudo using the audit tool or request for IT to update?
I can't even imagine writing a kernel hardware driver in a corporate setup if they at subjecting development environments to strict lockdown.
I worked in a bank previously. We did not have root, but we had a utility to run certain commands "as administrator". It popped up a dialog where you had to input a justification for auditing purposes.
I don't recall needing it for debugging though, even when attaching to a running process (was your process started as a different user?)
We either don't need it, or get stuck and end up crying in the bathroom.
Thing is, why do developers create software that needs administrative access to the os? I wish that I could simply download a zip of the software, extract it and run.
And already this wouldn't work: most software is distributed only through an installer. Heck, even PortableApps website distribute their portable products using an installer!
Which is to be expected since your core business is software. I work for a very large consulting company and I also have administrative access. But my client's machine do not - big insurance companies, banks, publishers, Telcos, petrochemicals, etc.
Why? Tell me, if you were a system's administrator in charge of 10.000+, would you risk it? That's everything that's bad in corporate culture, but as you get big, it happens.
> Atom: [...] must install a column mode extension
Atom has Sumblime-Text-style column selection using (on Win) CTRL-ALT; it works very well and feels familiar for people coming from Sublime Text (which has been very popular for years now).
Actually, column selection is one of the things where I prefer Atom to VS Code (I love both editors for different reasons).
But maybe you needed some particular style of column selection?
I've been using Sublime Text 3 for probably 2-3 years now at work (and home) and I love it. The only downside is it costs money but you can use it for free as long as you don't mind a popup asking you to purchase it every 10-20 saves.
I used Notepad++ for a few years before Sublime, I eventually switched because of the lack of Notepad++ support on Linux. I didn't want to have to remember the commands/shortcuts for two editors (and I avoid using Vim if I can).
In Sublime, Paste and Indent (Shift-Cmd-V on Mac) does that fairly well. It's not based on an AST or anything like that, but it's rarely failed to do the right thing in my experience with these: Python, XML, HTML, CSS, SASS, PowerShell, YAML, Ruby
For me, it's a robust extension API, because then I can have any feature I want given enough time. Atom definitely has an edge there imo. Performance is also a plus (I have no complaints there with Atom). VSCode looks promising, though.
Well, I can do this in vim, so... yeah. If it can't do these things (more specifically be extended to do these things), it's a text editor I'd quickly put down for one which can.
"I belong to a lower race: the corporate developer. I work in a Windows 7 machine, don't have root password and there's a big wall called proxy around me"
Sounds like an undeserving environment for a developer. Why not vote with your feet?
I live in Brazil. We have some striving software houses, but they are few and pay a lot less than, say, my employer, Bigtime Consulting.
To vote with my feet I'd have to accept an income downgrade of about 30%, higher risk of unemployment, and even then (heck, I'm looking for something like this right now) it's hard to find.
Because not everyone wants 20% below market rate, consntant negotiation headaches on stock dilution, an "infinite" vacation policy that actually means none, or being part of a culture that expects 70+ hour work weeks as normal, 3 months of maternity leave being ruinous to the company, etc.
It's a tradeoff, for sure.
But also most companies are waking up to the notion that trusted network models are not effective. It just takes time to change.
Ugh. 'Infinite' vacation policies are starting to infect corporaculture. I work for a megacorp (that I actually rather enjoy working for) that recently went this way, and since my megacorp is a bit of a trend setter, you can expect it to spread. During the explanation meeting, it was made clear that we really aren't supposed to take more vacation than what we used to have, but that we are expected to still actually take about as much vacation as we used to have ... so essentially a no-change there. As far as I can tell, it's mostly about
1) Making it so that employees can't take vacation at times that are particularly bad for a project because they're 'entitled' to it. This was already frowned upon (we always did get to use our vacation eventually, so it wasn't so bad), but now it's in writing -- which is good, rules should be written.
and, more importantly to the megacorp:
2) Eliminating owed vacation from their books & marginally reducing cost. Now if somebody quits or is canned, they're not owed a payout. I'm guessing the average employee will probably also take a couple of days less than they did under the old system, yielding a further savings.
I'm glad I live in a country where it's illegal not to pay out unused leave entitlements upon termination, and where there is a sensible statutory minimum leave entitlement...
I'm in a corporate environment too. The work is interesting and I'm slowly working with IT Security to break down the walls where needed, but I still find myself submitting bug reports like:
(Note that I've since found out it's better to support SSPI and NEGOTIATE)
That's before we even get started with SSL interception -npm/node and possibly Ruby's gem don't use the system cert list.
The answer is not to vote with my feet (because there are lots of reasons to stay) but work to make things better for developers in more restricted environments. Geez, wait til you startup kids go work for the Government one day ;)
If the developer needs access, the product will suffer for a lack of it, and customers will eventually leave. If not, then it's just a petty complaint.
A lot of people don't want a bloated editor with too much bundled in by default. I'd be incredibly frustrated if there was some vertical selection functionality built in if it caused issues with a Vim mode extension.
>Why not just set up atom to use your existing corporate proxy?
"Many of these text editors support proxy servers, but none of them that I have tried support NTLM for authentication and if your corporate proxy is using NTLM they simply cannot connect to it. Or lets say not directly! Actually the only solution I have found is to use a software called CNTLM that can act as a proxy server itself and behind the scene it can connect to another proxy server that is using NTLM." [1]
As to what needed a compiler, that part I'm not sure about. Aren't Atom extensions generally in javascript? Could it have been the CNTLM installer that wanted a compiler?
NTLM auth is but one of various other roadblocks in a corporate environment.
In my previous job, the company runs a MITM proxy, it broke SSL checks for package managers. You ended up having to disable SSL checks and load up company-issued certs.
I asked whether we can find a solution to this issue on the company forum, as there are other developers and data analyst whose life can be made easier if this just works, the response I get was: "just download them manually", I kid you not.
Sigh... corporate proxies are the worst software I ever had to deal with. Terrible for productivity. Enough that people bring in own 3g dongles and connect to that wifi instead. Whole audit/security defeated :(
I thought they were, but the simple installation of the column select mode failed with a message of missing compiler. I don't want to delve inside my editor internals.
The first difficult thing is to discover that I have to install the sublime-style-column-selection package. So it failed and didn't researched more.
Ops, I've just tried it to see the error message and it worked! The sysadmins just updated a lot of Windows patches, maybe it solved the problem. BTW: VSCodes starts a lot quicker than Atom.
Please report issues instead of using things like CNTLM - it has at least one bug that causes crashes under heavy traffic and may require you to store your password/hash in an insecure way.
I have admin and can install anything locally, but also I can't get any Atom packages to install from behind our proxy. That's okay -- I just wait until I have my laptop on my WiFi network at home and everything is copacetic.
It's not just me -- we had a trainer giving a class, & this guy lived and breathed Atom and he couldn't install an updated version of an existing package from our network either. His solution was to tether his phone.
I have the same problem with the Atom packages behind the proxy. I had to do some npm and git configuration to add http_proxy. It worked for a bit, then the corporate password changed, and I never really updated the buried settings.
I'll probably have a pretty easy time getting the MSFT Visual Studio Code approved for machine installation for devs on my team, even though we're an Eclipse/Java shop. I've been trying to get everyone normalized on a JavaScript editor, since the tools we have in Eclipse are severely lacking.
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!
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.
>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.
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.
"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.
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 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?
> 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.
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.
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.
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.
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.
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 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 :)
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.
> 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.
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.
> 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).
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
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.
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.
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?"
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.
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 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.
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.
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. :)
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 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.
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?
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.
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.
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 :)
> 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.).
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!!
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.
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.
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.
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.
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.
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.
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.
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).
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.
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
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.
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.
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.
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)
>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.
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).
> 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.
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!
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'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.
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.
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.
One of the things people does not seem to mention is the great debugging support you have in VSCode.
The possibility to easy setup debugging with support for breakpoint, step through, inspection and so on.
For react-native VSCode is the only IDE I have found which enables this. Previously one had to open Chrome and debug your apps from there, to have it inside the IDE makes it so more convenient.
The same goes for Node(which you also can do in Webstorm, but not free and open source) and as far as I can tell the only IDE you debug Go probably.
As an developer preferring solid IDE`s like VS and Eclipse with full debugging support it always feels like a step backwards when working with an language where this does not exists.
Does anybody else use several editors all the time? I use Emacs, Vim, Eclipse, Atom, and Intellij. I don't stick to one.
I wish I could stick to one editor but there is always some editor that does a way better job at a particular task. Each editor has its killer feature. I have tried turning emulation of emacs/vim on many editors to provide consistency and its never been really good. Thus I have several "default" keybindings in my head.
Because of this I try not to rely on too much magic or customization that any editor provides and instead write lots of shell scripts (Bash, Groovy and Python) to do code generation and to find things.
But I'm always wondering ... could I be more efficient by sticking to one.
VSCode will probably just become another editor I have lying around. Probably for Typescript.
I'd wager a lot of people (myself included) who prefer one editor really do this because it's just easier to mentally handle.
Because of that I wouldn't necessarily believe them (or again, me) if they told you they're more productive this way. I don't think It's necessarily true.
It's pretty much required to keep CUA hotkeys in your head in some form. So I find switching between Emacs/Eclipse tolerable and kind of necessary if I'm doing Java.
I think switching between Emacs and Vim is a good idea but more a question of keeping your hand/mind coordination flexible for different input paradigms. I'd be skeptical that they're really that different in terms of efficiency for a task, but I'd say learning both really well will make you more efficient in general.
I'm using Emacs all the time (slowly migrating towards using Vim keybindings; I tried Spacemacs for a while, but for now I'll stick to my regular one and Evil Mode) whenever I can get away with it. Unfortunately, my current job involves a lot of Java code, for which it is hard to beat Java IDEs in terms of suggestions / autocomplete. I'm too lazy to figure out how to make ECLIM work, so I'm switching back and forth between Emacs and Eclipse at the moment.
(I actually keep both open; Java files I edit in Eclipse, but pretty much anything else goes to Emacs. I also have Emacs keybindings and Emacs+ plugin installed in Eclipse.)
I'm constantly switching. Right now I'm on vim for js/html and IntelliJ for Java. I've used ST3 quite a bit. I used Atom for a while, Brackets for a while, VS Code for a bit.
The only thing that trips me up really is switching from vim to one of those others, and I sometimes run vim modes in those.
One of the major reasons I keep vim in my repertoire is that it is on every machine I have to SSH into and it can handle monstrous files. Vim is also better at editing config files (SSH ops stuff) in general since you are typically manipulating and not creating content.
Aside from different tools having different strengths, I enjoy learning to use new software. I think if I used one tool for everything I would get bored with it.
That said, learning new keyboard commands is sometimes a real PITA. When I'm tired, I sometimes find myself trying to close Visual Studio or Sublime Text with :q.
How odd. I've used the same text editor for twenty-plus years now (hint: it has yet to be mentioned) and I find that I no longer have to think how to use it---it just happens. Then again, I consider the Unix command line as my IDE [1].
[1] Every few years I'll try an IDE. I've been doing this for over twenty-five years. I've yet to find one that I like. Over time, my bar for "what I like" has fallen to the point where now it's "it doesn't crash when loading a simple one file program." [2]
[2] The C/C++ "version" of Eclipse. I tried using it to help browse a C++ application at work. It never worked.
Odd? I don't think so... I've worked with lots of incredibly talented programmers and I think every single one of them has different preferences.
My favorite place to work right now is on OSX. It's Unix so you get all the command line goodies plus it has a very good GUI and great tools in the graphical environment as well (I'm thinking of XCode). Plus, I think Objective-C is pretty neat.
I tried VSCode for the last couple of months and it didn't sell me.
It's noticeably slower than Sublime on a good workstation and it has a bunch of very minor annoyances that Sublime simply doesn't have.
When you encounter these annoyances dozens of times a day, it really turns you off from using it because a good editor should make you happy, not infuriate you.
For example, the way VSCode deals with multiple buffers and the sidebar is really poor. It tries to be cute and keep the sidebar's state in each buffer, but it's done really poorly and constantly disrupts you.
I feel the same way. I tried to like VSCode but it's just all the small things that trip me up. I've really come to depend on STs mini-map and miss it when it's not there. VSCode is just slightly slower than I feel it should be, causing me to pause and crash my train of thought.
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.
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?
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.
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.
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's interesting to see how VS Code / Monaco deals with long lines like hex data without slowing down. It kinda cheats by wrapping the line even when not in line wrap mode. There's a setting editor.wrappingColumn that controls the wrap length.
However, even after setting wrappingColumn to an arbitrarily large number, VS Code greatly outperforms Atom. The click accuracy within a long line is off by several characters in my quick test, but good enough.
I was never comfortable using Atom because it would grind to a halt whenever I accidentally opened any files with long lines. VS Code just may be the first MS product that I'll use on my Mac on a daily basis. Looking forward to testing it out on a couple projects.
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 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'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'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 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 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.
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.
For some reason I can't stand the fact that VS Code drops .vscode files all over my directories. I feel like I'm working with CVS again. I haven't played with it much and not at all lately, but the last time I tried editing anything in VS Code it generated these hidden files all over the place and drop me up a wall. That may be configurable and it may have changed with 1.0, I'm not sure.
It's also, just very slightly, too slow. By too slow I mean that everything I do just lags a tiny bit; I can type characters faster than it can put them on the screen, clicking in the file browser is not instantaneous, etc. It's a small thing but it really bugs me. I guess I'm just spoiled by ST3. :/
The two highest rated comments in this thread make the little vein in my forehead pop out.
Microsoft is doing some very cool stuff these days so props to them. "VSCode has done the thing that nobody expected MS to do, change the way code was written in Unix/Linux" though? I believe the term irrational exuberance applies. Let's not get carried away here.
> The two highest rated comments in this thread make the little vein in my forehead pop out.
There are some days when I wish that I had enough money to employ a small army of "thought leaders" to "organically" shape discussion on Internet Message Boards.
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'm quite surprised by how much smoother VSCode is than Atom despite being built upon the same platform, I just wish it had tabs and split tab groups, then I could give it a go for a full day and decide whether I like it or not.
The tabs feature is under the heading, "Initial investigations/explorations" something tells me they are not working on anything just yet. If the feature makes it through, we might not see it for sometime yet. Disappointing, tabs are a definite must for me.
I'm the maintainer of amVim.
I don't know if you tried amVim. It supports Visual and VisualLine.
Also, you may find it handles detail behaviors of Vim much better.
It looks like a big improvement, but I notice visual mode doesn't work with cursor keys, and I'm also not seeing an ex-mode (eg. :w). Would love to see these implemented :)
Thanks!
Cursor keys support in Visual mode will just be a few lines of code to implement.
Cloud you open an issue so we can track them easily?
https://github.com/aioutecism/amVim-for-VSCode
Oh. ex-mode is not something I'm planing to implement.
They are often a lot easier to do with Cmd+Shift+P.
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.
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 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.
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.
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.
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).
One thing I've gotten used to and find missing in VSCode (and Atom) is auto-saving of untitled/unsaved buffers to temporary storage.
When I have an idea or want to use a new editor tab as scratch space, it's really important to me that whatever I put there isn't lost if I exit the editor. When I close the tab, sure, ask me if I want to save it somewhere. But when I close the editor itself, I want it to reopen and restore everything exactly as I left it.
The last thing I want to deal with is coming up with a path and filename when the editor can easily create a temporary file and map some unique id to it for later use until I tell it explicitly to save or discard it.
I have an IntelliJ Ultimate license and although it's really powerful and great, for small things (JS, Python, etc) I mostly use VSCode.
So far I am really happy with it.
I would really like to use VS Code as my primary editor but it has some issues that need to be fixed first, most importantly how slow the go to file functionality is. I work on a project (Chromium) that has tens of thousands of source files and while Sublime Text can handle that without issues, VS Code can't.
I would also like to see the C++ intellisense plugin that's under development improved further. I've found it to be a lot slower than QtCreator at indexing symbols.
Anyone know how to "fix" the issue where I paste in a block of html and it doesn't line up and indent properly? This works as I would expect in Sublime.
(linux) webdev here, so I write in a couple of different languages.
I believe vscode sits nicely between emacs and eclipse.
emacs on the console at the servers is unbeatable. the daemon just sits there, and I can fiddle with bash, config files, php, css with ease.
As a full IDE, eclipse is still the best for PHP development. Has a myriad of plugins that make it so powerful: pdt, phpunit, code/lib/docs integration, per project configuration, etc. its amazing!
Now, for js and scss, its a bit more complicated. and this is where vscode is shining for me. I had to learn a few command bindings and a few things are weird for me still: ctrl+x yanks the line, on linux middle click isn't default, "folders"...
One of the things I like the most tho, it is written in a language I can understand. Aptana used to be a favourite of mine, but because I couldn't write any code for it, I was limited to bug reporting and waiting. This being in typescript, I feel I can look into the source code and write a PR.
I yet to explore it deeply, but i'm sure it will just get better and better.
I'm a long time vim user who's switched mostly to Atom(at least for bigger projects, vim is still my "quick fix" editor). Last time I tried VS Code(6ish months ago?), I liked it all right, but stuck with Atom because at the time the availability of vim like bindings was weak and ruby support was lacking.
Mostly tried it and got used to it. I liked the defaults a lot more than I do vim(nothing some plugins, a good .vimrc, etc can't fix), and I found it much more natural to use extensions that I ever did vim, so once I got Atom matching my usual vim setup I found myself extending beyond that. Most of it's probably stuff I could do in vim too, but adding extensions on whim feels a bit more natural in Atom.
I still spend a lot of time on remote systems, so vim is a big part of my tool box. There's also the weight of Atom. If I'm working on big project, I get it all loaded up and work in Atom, but if I just need to tweak a thing or two in a file, vim is still my go to.
I asked because so much people say "If you're serious about development then you need a serious editor: you should learn vim/Emacs because it's a once in a lifetime investment that will boost your productivity beyond what other tools provide". This mantra doesn't match my own experience.
I think Atom and VSCode provide 3 main advantages over vim: the out of the box experience is better; using a GUI offers a more powerful user interface; extensions are easier to install and work better.
It's like comparing fish and zsh: Atom and VSCode are more like fish; vim and Emacs are like zsh.
I've played around with VS before but, I'm thinking of switching over to this full time. I've gotten sick of the time wasted on TypeScript Errors in Webstorm, the code Completion and Typings info is ridiculously better than Intellijs offering, which has moved to SAAS :(
The one thing that prevented me from switching to VSCode last time I tried it was the lack of projects management (e.g. a project remembers what files were open, what folders are associated with it, and you can quickly switch between projects, like the CTRL+ALT+P list in Sublime Text).
Yes, the lack of a built-in project switcher is a nuisance. I'd like to have a little dropdown at the top of the (left) sidebar with project names. A keyboard shortcut plus a bit of fuzzy matching drops down the list and picks a project and pop all the files in that project are loaded right where I left off. Maybe copy a few lines to the clipboard, maybe add a TODO: note to myself that just occurred to me while working on something else, then a quick keyboard shortcut and pop I'm back in the other project.
Switching between multi-file projects should be almost as easy as switching files within a project.
I had a similar question - One of the things I appreciate about Atom and Sublime is the ability to add folders to current "project" even if they are at different hierarchical levels of the folder structure. Other than that VSCode was pretty cool.
Typically a SublimeText & Emacs user here. Decided to check VSCode out. Can't ctrl+shift+[a/e] to highlight to beginning/end of line? Bummer. Also, seems utterly unable to find defined symbols within a Python class within an open file--but finds non-class functions and imports as symbols just fine. It's jump-to-def is significantly better than I've seen in ST, and the peek-at-def is pretty nice. I am quite impressed with its speed, especially when near-instantly showing tooltips with the docstring descriptions when hovering over classes/functions.
Overall, fairly impressed with 30 minutes of play.
Yet again, just like the other Microsoft announcements, this thread is filled with "greybeard" superstition and vitriol.
It's to the point now where the conversations are becoming like this:
"I really like this new tool from Microsoft"
Samples Response:
"But Linux is just as good if you install X, Y, Z and are willing to spend hours learning the intricacies of the kernel"
"Embrace, Extend, Extinguish"
As developers, can we all be happy that Windows users are finally getting a nice range of really wonderful tools to use?
Not everything in computing needs to be a great ideological battle, especially when the majority of us are writing simple line of business apps in our day to day careers.
EDIT: Ok, forget it, I just have to press Tab twice.I thought it was strange that they launched an editor without that feature.
Original Post:
I like working with VS Code, although I'm just starting out.
But one thing bugs me: Is there a way to get VS Code to automatically complete the tags and add the closing tags?
I know about intellisense, but I fail to activate something like autocomplete. I know about Intellisense, but I'd like something that, for example, just fills in <div></div> when I am writing <di + ENTER.
I know some other editors have that feature and I know it got disabled in VS Code because of problems - can anyone elaborate and explain why?
I think VSCode is amazing - if only I could change the colour of the blue status bar. I find it highly distracting. There's a Github issue about it, with MS saying that they may add more general customisation support in the future, but it doesn't seem like there's a short term solution.
I know it seems like such a minor thing, but I can't have that attention seeker on my screen. Which is a bummer, because I think IntelliSense and its Git integration are clear benefits over Sublime Text. And apart from this issue, I really, really like the UI.
When I started using TypeScript a couple weeks ago I briefly tried out VS Code, but the VIM plugin was really, really bad (worse than Sublime's was when I used it a few years ago).
Now I'm on Atom, which has the best VIM support I've ever seen (haven't tried evil-mode, though) and seems to support a similar feature set. They felt about the same speed, too, on this 2013 Macbook Air.
Regardless, other than that quirk, I did really like VS Code, and I'm glad there's more competition in the free editor space :)
Atom's vim support is OK, but nowhere near the best. Kate (KDE), IntelliJ, and emacs EVIL all offer better support (others may, but I haven't used them). I completely agree that Atom is way ahead of VS code in vim support.
I use Atom a lot, but I wish it had support for the goto column command (pipe), proper search/replace support (it does weird things with the trailing slash, deleting words at the end of lines, and macros.
There is no "the VIM plugin". There are multiple extensions created by VSCode users. One of them just happens to have had the temerity to re-use the logo from Bram Moolenaar's project and slap the "Vim" label on their extension.
And it's working. Despite having messier code, performance problems, and fewer Vim features implemented, it has over 3x as many users as the next most popular one listed in the VSCode extension gallery.
Just piggybacking on this thread to ask if there is a way to configure the editor so it accepts the spread operator? I'm getting errors and my Google Fu is failing me.
This is mentioned in the release notes for 1.0.0 [1].
Their suggested solution is to disable built-in JavaScript validation entirely and rely on ESLint instead.
> Some users want to use syntax constructs like the proposed ES7 Object Rest/Spread Properties. However, these are currently not supported by Salsa and are flagged as errors. For users who still want to use these ES7 features, we have revived the javascript.validate.enable setting to disable all built-in syntax checking.
Ah, yes. Yet another thread in which HN devolves into hyper-religious zealots arguing over their favored denomination of code editor being the one true way.
I use VSCode for ReactNative projects and absolutely love its built-in debugging capabilities. With its clean and vivid UI, it makes my code look beautiful.
First impressions: felt great, supported a ton of languages, has some very powerful looking debug tools (for nodejs)
Anyone have any luck creating an extension with mac classic? Tried manually adding the theme (following their doc) and no luck. Then created a msft account to try and create a package to install it as an extension and couldn't get past 401 on create-publisher.
Back to sublime for now, but I'll keep an eye on this one.
I find Visual Studio Code much better with plugins than Atom. Atom died after installing the Nuclide plugin suite and would not work until I uninstalled those plugins. Code on the other hand runs plugins in a separate thread meaning it does not tend to dies so easily. VS Code rocks!
The link says: "or if you already have a project with C# files, VS Code will prompt you to install the extension as soon as you open a C# file.". As a matter of fact, it doesn't.
I made the switch to linux in 2005. There's always been two tools I've sorely missed since that transition: excel and visual studio. Glad to see the latter finally come.
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.
For web development, java scripting and rails dev I find Brackets to be the best (http://brackets.io ) , Its super easy to setup and much better than VS Code 1.0
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."
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.
5. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the software. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not
* work around any technical limitations in the software;
* reverse engineer, decompile or disassemble the software, or otherwise attempt to derive the source code for the software except, and solely to the extent: (i) permitted by applicable law, despite this limitation; or (ii) required to debug changes to any libraries licensed under the GNU Lesser General Public License which are included with and linked to by the software;
* remove, minimize, block or modify any notices of Microsoft or its suppliers in the software;
* use the software in any way that is against the law; or
* share, publish, or lend the software, or provide the software as a hosted solution for others to use, or transfer the software or this agreement to any third party
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.
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.
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?
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.
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.
> As someone who uses Visual Studio for everything...
This is a classical hammer/nail example. Big red sign to me.
I'm a long time Visual Studio user, and that what you are saying is exactly the problem I see in MS-based developer circles.
Visual Studio is not appropriate for everything. As a matter of fact I don't use it at all for SPA development anymore, but just for server side stuff.
However, to give you few arguments:
1. VS Code and Sublime work on Linux/OSX/Windows and I do work on all three of those. Having the same tool is a great gain here.
2. Editing capabilities of VSCode and Sublime are definitely superior to Visual Studio, to the point that I find myself copying pieces of code from Visual Studio to Sublime, editing it and pasting back to Visual Studio.
3. Speed is not comparable. Visual Studio has become a bloated beast. Sometimes it takes a minute to start it, and then you enjoy busy freeze times whenever you push it just a bit harder than it likes.
All in all, I find my self being much more productive when not using Visual Studio for anything except pure .NET development.
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.
Sure, you all have root password in your computer. Unfortunately, I belong to a lower race: the corporate developer. I work in a Windows 7 machine, don't have root password and there's a big wall called proxy around me.
I didn't know about VSCode before this HN post, but I was trying to use a new editor instead of Notepad++. In my 5 minutes comparison match between Atom and VSCode, Atom was knocked out in the first minute. To quickly test a new general code editor I just want 3 "simple" things: column selection, regexp search and replace, and a python mode.
Atom: got the regex, must install a column mode extension, need to install a ntlm proxy authentication downloaded from (argh!) Sourceforge, configured it after some google searches, failed to install the extension because it needs a compiler. Ops, just spent 30 min for my 5 min test. Can't spend more time playing with a code editor, must go back to work.
VSCode: Download the portable version https://code.visualstudio.com/docs?dv=winzip and unpack it. Just works.
You've got a new fan VSCode!