Visual Studio Code 1.9(code.visualstudio.com)
code.visualstudio.com
Visual Studio Code 1.9
https://code.visualstudio.com/updates/v1_9
311 comments
I concur, the Go plugin is top notch. It even has a fantastic vim emulation plugin that works reasonably well.
It does. The only things quirky about it: command mode "up" button doesn't know about the history of past commands... Sucky for iterating on a regex. Undo is also broken, but it took me 2 full months to notice that the vim plugin broke undo!
> makes it the best Go IDE out there
I will respectfully disagree and say that gogland (while still in a pre-release state) is much much better.
I will respectfully disagree and say that gogland (while still in a pre-release state) is much much better.
In what way is it better? Go in VSC is very, very nice. I can't think of any tooling I don't have available with this setup.
Gogland is great, but so far I haven't seen a feature that makes is strictly better, but I agree that it is a great alternative.
There is also the fact that VSCode is open-source.
There is also the fact that VSCode is open-source.
IntelliJ is open-source as well and the Go plugin for it has been open-source for a long while as well :)
Anyone know if it works with the app engine runtime for go? I've never gotten anything to work for that except IntelliJ.
How does it compare to LiteIDE?
I never understood LiteIDE, it was always extraordinarily esoteric and nonintuitive. VS Code is just fantastically better in comparison, in my opinion.
I have never heard of that, but I will share one thing I like about it as an IDE (and historically I have hated IDEs and used vim)... No config. Open a "folder", no project setup bullshit, and it remembers your work-state for each project/folder you open... And best part: autocomplete! But it is not heavy and slow. It does autocomplete per-file. So it does not need to analyse my entire project codebase, it just sees I used a word before and lets me tab to complete. So nice.
I loved LiteIDE when I used it, the VSCode extension can do most of what LiteIDE does but in a much nicer UI and control.
All editors support go really well, that's because go has official tools that integrate with editors (guru, for example).
At the top of the read me is the feature list for the vscode-go:
https://github.com/Microsoft/vscode-go
This is the feature list for vim-go:
https://github.com/fatih/vim-go
looks a little longer, but if you notice they both use the same back end tools. I see that VSC has partial delve integration, but vim running inside tmux makes delve (and every other CLI tool) feel like it's already integrated. I don't use debugging that much with Go though.
At the top of the read me is the feature list for the vscode-go:
https://github.com/Microsoft/vscode-go
This is the feature list for vim-go:
https://github.com/fatih/vim-go
looks a little longer, but if you notice they both use the same back end tools. I see that VSC has partial delve integration, but vim running inside tmux makes delve (and every other CLI tool) feel like it's already integrated. I don't use debugging that much with Go though.
Yeah, I know they all make use of godef, guru etc. but the way VSCode allows you to see declaration/documentation or full implementation on hover, integration with dlv etc. make it a nicer implementation for me than vim-go, but that's probably because I am not a ViM person myself.
VSCode really does improve with each release, and the monthly cycle is just about the perfect pace. This is a great example of how to run an OSS project.
I wonder how much Microsoft spends on it each month, and what value they see in it? Is it just a marketing expense? e.g. They fund VSCode in order to gain the good will of developers which they hope will turn into Azure or maybe Windows sales in the future?
I wonder how much Microsoft spends on it each month, and what value they see in it? Is it just a marketing expense? e.g. They fund VSCode in order to gain the good will of developers which they hope will turn into Azure or maybe Windows sales in the future?
It's probably a complex set of factors including developer good will and competition in the marketplace (VSCode is obviously directly competing with Atom, for instance, which is also free).
One interest small piece of the larger puzzle is that the Monaco text editor at the heart of VSCode was originally built for Azure and Visual Studio Team Services cloud editing. It was then also subsequently embedded into IE's Dev Tools (and now Edge's Dev Tools). It's a neat example of building a tool for several existing needs embedded into existing products/projects and then finding that the same tool was also interesting as the core to its own product.
One interest small piece of the larger puzzle is that the Monaco text editor at the heart of VSCode was originally built for Azure and Visual Studio Team Services cloud editing. It was then also subsequently embedded into IE's Dev Tools (and now Edge's Dev Tools). It's a neat example of building a tool for several existing needs embedded into existing products/projects and then finding that the same tool was also interesting as the core to its own product.
VSCode vs Atom (in my opinion) isn't even a contest. Maybe Atom is super nice for some web dev stuff, but as a full flown IDE I just don't see the features.
Are you confusing VSCode with Visual Studio? VSCode is not an IDE, it's an editor, much like Atom.
Vscode is an IDE. It integrates all your development into one environment. It comes with support for version control, code editing, task running, and debugging all from one application.
Microsoft is smart not to call it an IDE. As that would drive hipsters away.
From the FAQ:
Visual Studio Code is a streamlined code editor with support for development operations like debugging, task running and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs.
So, even Microsoft doesn't think it's a full blown IDE. With enough plug-ins it certainly could be.
Visual Studio Code is a streamlined code editor with support for development operations like debugging, task running and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs.
So, even Microsoft doesn't think it's a full blown IDE. With enough plug-ins it certainly could be.
That last sentence strikes a chord. Most IDEs are basically heavy-weight plug-in platforms (especially Eclipse and IntelliJ), built with the intent of being heavyweight IDEs. The currently popular editors - ST, Atom, VS Code - and the console-based editors that are still popular - Vim, Emacs, etc - approach it from the other side, putting text editing (including search etc) first, then adding plugins on top of that.
Or maybe put differently, IDE's are enterprise software, editors are agile startups?
Or maybe put differently, IDE's are enterprise software, editors are agile startups?
An IDE is so much more. For instance, refactoring features. Even Microsoft defines VSCode as a "code editor" and not an IDE.
Think of "code editor" and "IDE" as two endpoints on a continuum. VsCode is less of an IDE than Visual Studio or Eclipse, but more of an IDE than Atom.
It has has debugging and task running, after all. Sounds a lot like an IDE.
It has has debugging and task running, after all. Sounds a lot like an IDE.
Exactly, it never ceases to amaze me how often people arbitrarily categorize stuff as is/isn't
Have you even used VSCode?
It has refactoring, and revision control integrated. You can compile and run code, you can set breakpoints and step through execution. That's waaaaay more than just an editor.
It has refactoring, and revision control integrated. You can compile and run code, you can set breakpoints and step through execution. That's waaaaay more than just an editor.
As someone who started on FoxBASE, Turbo BASIC and Turbo Pascal (all for DOS), it's amusing to read comments like these. We certainly called these things IDEs, and the sole reason was that you could build your program directly in them, and the debug it, breakpoints and all.
I wonder what someone coming from an earlier era would have to say on that...
I wonder what someone coming from an earlier era would have to say on that...
VSCode does have basic refactoring features.
I don't think refactoring was even a term when the first IDE's came out.
If there's some sort of editor-IDE spectrum, VSCode likely lives closer to the IDE side than editor.
Possibly? VSCode stands for Visual Studio Code (https://code.visualstudio.com/) right?
I've just seen most comments referring to it as an IDE.
I've just seen most comments referring to it as an IDE.
> They fund VSCode in order to gain the good will of developers which they hope will turn into Azure or maybe Windows sales in the future?
I think they are just trying to make Windows (and Microsoft) more relevant among web/foss developers by making sure that top-notch tools exist with first-class Windows support, so this falls to same category as Windows Subsystem for Linux.
I think they are just trying to make Windows (and Microsoft) more relevant among web/foss developers by making sure that top-notch tools exist with first-class Windows support, so this falls to same category as Windows Subsystem for Linux.
VS Code is part of the strategy to get .NET Core distributed and to support the web layers built on top of that which mostly now use open source technology (from npm and bower through to grunt, typescript and angular)
Na, I think the real plan starting to unfold. This week we get the new welcome screen, next will be the "deploy to Azure" and "how to make a Windows Store App" sidebar links.
(not that I'll stop using it, I'm sure someone will fork if gets too obnoxious)
(not that I'll stop using it, I'm sure someone will fork if gets too obnoxious)
Wow that is a scary vision and it would be heartbreaking if they rendered it unusable with ads or other nagging "features".
I doubt they will do that, they know that the project's success is 90% based on developer goodwill.
My guess is that they will up-sell to a version with bundled plugins which offer turnkey integration with Azure.
My guess is that they will up-sell to a version with bundled plugins which offer turnkey integration with Azure.
It's the only practical way to do cross-platform .NET Core development.
Project Rider?
If that's true, then I'd recommend not using either .NET or VSCode if cross platform matters to you.
Historically speaking, Microsoft will break compatibility when it suits them.
Historically speaking, Microsoft will break compatibility when it suits them.
The project is Open Source, MIT licensed. If they break compatibility you (or someone else) can just fix it. No difference from any other OpenSource editor.
I think you confuse Microsoft with Apple.
Are you talking about csproj -> project Jason ->
I assumed the idea was also to eventually to get some users to move to the "real" visual studio, which I ended up doing at least to debug C++, except the vs editor is so much worse!
For example, I use Ctrl+D for multiple editing all the time and I converted other people to vscode based on that feature alone, yet it does not exist in visual studio...
For example, I use Ctrl+D for multiple editing all the time and I converted other people to vscode based on that feature alone, yet it does not exist in visual studio...
I'm probably wrong, but I get the feeling VSC is where all the MS devs that were fed up with Visual Studio politics moved to. They're able to get new features rolling much faster, rather than going against the ingrained assumptions of an Enterprise Application like VS.
I loved VS, but pro much stopped using it after starting to use VSC.
I loved VS, but pro much stopped using it after starting to use VSC.
VS Code is a web dev IDE. Microsoft has lost the mobile platform wars and pushing the web is a way of countering that. Plus, web and azure do go hand-in-hand, as you point out.
Nothing in VS Code is terribly web specific. I've been using it for C++ for which it works swimmingly.
The personal preferences file includes several defaults for S/CSS, HTML, JS and TS, and it has a lot of Typescript stuff out of the box, some node stuff.
Right, but VS Code's depth into other languages and stacks is quite extensive, as well. If I were promoting a new text editor (hell, or any piece of software), I would certainly set the most-visible defaults to hit the most common use case, which at the moment is web front-end oriented tasks. To get a fairly full featured C++ experience, VS Code is up and running in three mouse clicks and two text fields from the splash screen -- this includes automated downloads and installs of major pieces of Clang tooling. I also write a fair amount of more data-centric Python, and the experience is similarly painless (I haven't tried Rust or Go, but if f*ing C++ is this easy I can't imagine other stacks are worse), so I don't think I'd call it web centric at all!
I wonder what set up you have for c++ in VCode (plugins etc) I'm learning c++ at university and currently I use CodeBlocs since it have quite nice code completion.
I would like to try it for native development. How do you run and debug your C++ programs from VSCode?
https://code.visualstudio.com/docs/languages/cpp
> VS Code supports tasks that you can configure to build your application, and natively understands the output of MSBuild, CSC, and XBuild.
> VS Code supports tasks that you can configure to build your application, and natively understands the output of MSBuild, CSC, and XBuild.
Yes, building works well. But how do you run your application?
(To be clear I'm asking what workflow users use personally, since it seems like nobody else has this issue.)
(To be clear I'm asking what workflow users use personally, since it seems like nobody else has this issue.)
For me, I build on the command line, because I have a funky build process, and then when I want to debug it I just press the 'debug' button.
There's a big JSON file with the debug configurations, and a drop-down to allow you to select which one is active. Each gdb debug configuration lets you specify the usual binary path and command line arguments, plus a whole lot of other configuration I haven't looked at. I haven't had to do any project-style setup --- it just magically finds all my source files.
It looks like it supports gdb on Windows and Linux and lldb on OSX (only ever tested on Linux, though). Out-of-the-box you get sample configurations to both run and attach to a C/C++ binary.
gdb integration is pretty seamless; breakpoints, conditional breakpoints, stack traces, local and global variables. Haven't seen threads, watchpoints, or an assembly window yet. There's a debug console, but entering commands doesn't appear to send them to gdb.
It's one of the best Linux gdb environments I've seen (even though most gdb integrations are terrible).
There's a big JSON file with the debug configurations, and a drop-down to allow you to select which one is active. Each gdb debug configuration lets you specify the usual binary path and command line arguments, plus a whole lot of other configuration I haven't looked at. I haven't had to do any project-style setup --- it just magically finds all my source files.
It looks like it supports gdb on Windows and Linux and lldb on OSX (only ever tested on Linux, though). Out-of-the-box you get sample configurations to both run and attach to a C/C++ binary.
gdb integration is pretty seamless; breakpoints, conditional breakpoints, stack traces, local and global variables. Haven't seen threads, watchpoints, or an assembly window yet. There's a debug console, but entering commands doesn't appear to send them to gdb.
It's one of the best Linux gdb environments I've seen (even though most gdb integrations are terrible).
Threads are part of stack trace - if you look closely, it has nodes for threads, if you have more than one thread running.
If you attach or launch more than one process, that's where they will appear also, as top-level tree nodes.
If you attach or launch more than one process, that's where they will appear also, as top-level tree nodes.
[deleted]
[deleted]
They lost the mobile phone, but I bet they will win the hybrid tablet/netbooks one, given how Android tablets disappeared from many consumer shops here in Germany, only to be replaced by Windows 10 ones.
Samsung and Asus ones seem to have been the surviving brands and even they have Win10 devices on their brand sections.
Samsung and Asus ones seem to have been the surviving brands and even they have Win10 devices on their brand sections.
>They lost the mobile phone, but I bet they will win the hybrid tablet/netbooks one, given how Android tablets disappeared from many consumer shops here in Germany, only to be replaced by Windows 10 ones.
That could just be a regional anomaly.
That could just be a regional anomaly.
Then it is an European regional anomaly, because I have seen it in other countries that I visit regularly (southern Europe).
On the other hand, speaking about regional anomalies, I almost never seen Chromebooks on sale, or people using them. Yet they apparently sell like hot cakes in US.
On the other hand, speaking about regional anomalies, I almost never seen Chromebooks on sale, or people using them. Yet they apparently sell like hot cakes in US.
Can confirm that this is the case here in the UK as well.
It is also the case in Australia, based on my experience Windows tablets are at least as common as Android ones. If it's a regional anomaly, that has to be a very wide region then :-)
Jokes apart, I have noticed that in developing countries (I regularly visit Thailand for example) Android tablets are still more common than Win 10 ones, I believe it's because in those countries many people were first exposed to computing in the form of a smartphone, so they prefer a mobile OS like Android, whereas in the western world most people (except perhaps very young people) were accustomed to use a personal computer long before they even had a smartphone.
Jokes apart, I have noticed that in developing countries (I regularly visit Thailand for example) Android tablets are still more common than Win 10 ones, I believe it's because in those countries many people were first exposed to computing in the form of a smartphone, so they prefer a mobile OS like Android, whereas in the western world most people (except perhaps very young people) were accustomed to use a personal computer long before they even had a smartphone.
No they won't. No one wants to use clunky non touch optimized windows desktop apps on a tablet. Besides, UWP was a failure.
Ever heard of Project Centennial?
Or the fact that all new APIs are mostly UWP only?
Or the fact that all new APIs are mostly UWP only?
Yes, and how's that coming along? Is this "project" supposed to make those old clunky non touch optimized windows desktop apps suddenly usable on a tablet? I don't think so. Instead its going to be another failure just like Project Astoria and Project Islandwood.
Astoria was the start of a lot of the technology behind the Windows Subsystem for Linux, if i remember correctly. I use WSL every day, so that was definitely not a failure in my book.
This is a ridiculous comment. There are plugins for every language. I use VS and I don't use it for HTML/CSS or Javascript yet.
I've never heard of VS Code referred to as a web dev IDE - what makes you say that?
Well, the Task Runner has preconfigured options for Grunt, Gulp, npm, maven, and TypeScript, but not make, ghc, cargo, etc.
That's pretty nice then - I haven't used it much at all, but I've read a fair bit about it. Thanks for the information!
I use it full time for C, Go, Python, Ruby and NodeJS development. Works well with Rust as well. Nothing "web"-specific about it, really.
Python and CloudFormation here. Others swear by the Golang support.
Another great release!
Maybe I'm just squarely within the target audience of VSCode, but I'm consistently impressed by how many of my pain points just magically go away with each new iteration.
Maybe I'm just squarely within the target audience of VSCode, but I'm consistently impressed by how many of my pain points just magically go away with each new iteration.
I come from WebStorm, Sublime and Atom.
Atom and WebStorm felt rather clunky. Sublime was super fast, but somehow lacked behind in new features.
VSCode is a revelation for me :)
Atom and WebStorm felt rather clunky. Sublime was super fast, but somehow lacked behind in new features.
VSCode is a revelation for me :)
I had to move off WebStorm after the sheer amount of memory it used to chew up.
Agree - VSCode is such a good IDE, I'm constantly seeing it replace editors other devs have relied on for some time.
Agree - VSCode is such a good IDE, I'm constantly seeing it replace editors other devs have relied on for some time.
whenever I try Webstorm, my laptop starts sounding like an Airbus A380. What makes VSCode different from Atom though is, VScode uses Monaco which is significantly better and also the start up is faster with VSCode.
Yep exactly my experience with Android Studio, to the point I started enjoying Eclipse again.
I miss the test runners from WebStorm, that hasn't been enough to stop me from switching to VSCode though.
How are other people doing ES6 work with WebStorm?
---
I am a very happy Jetbrains customer (ultimate, paid in full).
Now doing nodejs work. (Not a fan, it's just a job.) Really want to use latest, greatest (eg await/async). I tried to make the babel plugin workflow thingie work. Bleh.
I'll give VSCode another shot. Last effort, I stumbled on the npm package.json support. The npm plugins I tried baffled me. (Again, not a fan of npm, it's just a job.)
---
I am a very happy Jetbrains customer (ultimate, paid in full).
Now doing nodejs work. (Not a fan, it's just a job.) Really want to use latest, greatest (eg await/async). I tried to make the babel plugin workflow thingie work. Bleh.
I'll give VSCode another shot. Last effort, I stumbled on the npm package.json support. The npm plugins I tried baffled me. (Again, not a fan of npm, it's just a job.)
I have used vim for years and I was tasked with making an Electron app for a client so I tried vscode... And I love it! I still use vim for sysadmin things but it has been the first thing Microsoft has made since the original Natural Keyboard that I absolutely love. It is good. I recommend it to others. I hate bloated editors and it is good... No config/setup process either - the defaults are enough!
I do tweak a few of the defaults. I use it on windows, linux and mac and they vary, so I like them consistent (linux line endings by default, 2-spaces, etc).
I agree that it's one of the best products from MS today... I keep hoping that they take this as a model and re-create SQL Management Studio as an Electron app as well (I know about the VS Code extension).
I had tried electron and brackets before VS Code, and was skeptical... other than a few learning curves in the UX, it's been great. I don't think anything compares in terms of the plugin ecosystem either (though might not quite mach sublime).
I agree that it's one of the best products from MS today... I keep hoping that they take this as a model and re-create SQL Management Studio as an Electron app as well (I know about the VS Code extension).
I had tried electron and brackets before VS Code, and was skeptical... other than a few learning curves in the UX, it's been great. I don't think anything compares in terms of the plugin ecosystem either (though might not quite mach sublime).
I'm very curious: Don't you miss Vim? After using it for years, doesn't editing code in anything else feel wrong?
I'm all day switching between VSCode and Vim. VSCode's support for my toolset (nodejs, es6, jsx, flowtype, mustachejs...) is fantastic, but even with the (fairly good) Vim plugin, I miss Vim. Whenever something doesn't work in Vimified-VSCode as I expect, it breaks my brain and my focus a bit.
What's so great in VSCode that you abandoned something that, I imagine, was embedded in your head already?
I'm all day switching between VSCode and Vim. VSCode's support for my toolset (nodejs, es6, jsx, flowtype, mustachejs...) is fantastic, but even with the (fairly good) Vim plugin, I miss Vim. Whenever something doesn't work in Vimified-VSCode as I expect, it breaks my brain and my focus a bit.
What's so great in VSCode that you abandoned something that, I imagine, was embedded in your head already?
This is an off topic, but I just learned from the article that PowerShell will soon be the default in place of cmd.exe in Windows 10. I welcome this change as I found the experience of using PS was superior to that of bash/zsh in general cases.
But I hope they figured out the performance problem. As of writing, in the stable version of Windows 10, PS is perceptually slower than cmd, so I was forced to use PS only when needed. Funnily it was even slower in Windows 8, so the current affair is better than ever. But to be truly a default I think the performance of PS should at least match that of cmd.exe.
But I hope they figured out the performance problem. As of writing, in the stable version of Windows 10, PS is perceptually slower than cmd, so I was forced to use PS only when needed. Funnily it was even slower in Windows 8, so the current affair is better than ever. But to be truly a default I think the performance of PS should at least match that of cmd.exe.
On that note if you are a .NET developer you owe yourself to learn PS and how to write cmdlets, it's such a powerful and easy way to expose a CLI for your .NET app compared to stdio and command line arguments parsing - it's incredibly powerful and trivial to do.
Unfortunately most .NET devs are programmers who grew up with VB, RAD and GUI tools they don't understand the value of exposing UNIX like small functionality CLI commands over big monolithic services, GUI apps, etc.
Unfortunately most .NET devs are programmers who grew up with VB, RAD and GUI tools they don't understand the value of exposing UNIX like small functionality CLI commands over big monolithic services, GUI apps, etc.
I learned C# with a big fat book, and the command line compiler... I understand the usefulness of command line applications.
However, when I need more than what a simple shell script gives me, I'm more inclined to reach for node, ruby or python than C#/.Net ... the overhead for a quick scripting environment is quite a bit lower than having to setup a project and build requirements. I've done both...
Why node, is simply npm... create a directory, npm init, write my script, etc. reference it from an alias or .cmd in my ~/bin directory (added to my path). Then it works in windows, mac and linux which I use all regularly. PS is mostly windows.
However, when I need more than what a simple shell script gives me, I'm more inclined to reach for node, ruby or python than C#/.Net ... the overhead for a quick scripting environment is quite a bit lower than having to setup a project and build requirements. I've done both...
Why node, is simply npm... create a directory, npm init, write my script, etc. reference it from an alias or .cmd in my ~/bin directory (added to my path). Then it works in windows, mac and linux which I use all regularly. PS is mostly windows.
Have you ever written a commandlet ? This is my point, regardless of how you feel in PS vs Bash or Python vs C# - exposing your application logic trough commandlets is incredibly simple and powerful - much simpler than doing a CLI app in other languages even with argument parsing frameworks in python and likes, commandlets let you pipe and return/accept .NET objects.
So my comment isn't PS everything or C# everything, it's if you're using C# to write a big fat monolithic app that has multiple isolated functionalities you can expose those fairly easily with PS.
So my comment isn't PS everything or C# everything, it's if you're using C# to write a big fat monolithic app that has multiple isolated functionalities you can expose those fairly easily with PS.
I'm a .net developer, I still install cygwin/bash on my computer because I can write stuff quicker and better. PS get's incredibly verbose for anything non trivial. I learned powershell long before bash too.
Calling Powershell incredibly verbose is about the same as calling C# incredibly verbose.
Sure, perhaps they're not as compact as some of the incredibly information-dense perl scripts that people come up with.
I'd wager though that it's easier to understand what a random powershell script is doing than a random perl or bash script that pipes output throgh a dozen utilities.
Sure, perhaps they're not as compact as some of the incredibly information-dense perl scripts that people come up with.
I'd wager though that it's easier to understand what a random powershell script is doing than a random perl or bash script that pipes output throgh a dozen utilities.
I've got an example of powershell getting verbose here: http://flukus.github.io/2015/03/13/2015_03_13_Powershell-is-...
. Ignore the rest and look at the example where I'm trying to copy a directory recursively and with a filter. In bash the same task is a relatively simple one liner:
find . -type f -name '*.html' -exec cp {} /home/new_dir/{} \;
Well, how about this:
I think you're mistaken about what `cp` (`Copy-Item`) is intended to do. Its main purpose is to copy, not to filter. Yes, `Copy-Item` supports filtering because it's part of the "common parameters", but to be more in line with the cmdlets' original purposes, you should `ls` (`Get-ChildItem`) first, because it has more filtering capability, and then pipe the results to `cp`.
Is it complex? No, actually its complexity is exactly the same as that of your `find` example! `find` is more or less equivalent to `ls` in that both gathers the list of files that meet certain criteria. And then, like `find` invokes `cp` multiple times to do actual copying, `ls` (`Get-ChildItem`) feeds its result to `cp` (`Copy-Item`). They are structured in a similar way.
I'd even say the PS one-liner is more akin to "the UNIX philosophy". In the bash one-liner, there is a direct parent-child relationship between `find` and `cp`, which doesn't utilize pipes at all. Whereas the PS one-liner connects two equivalent processes (`ls` and `cp`) with a pipe. This is exactly what I'd call "small processes work together to get the job done", which is again the UNIX way.
ls . -r -file -fi *.html | cp -d /home/new_dir/
I think you're mistaken about what `cp` (`Copy-Item`) is intended to do. Its main purpose is to copy, not to filter. Yes, `Copy-Item` supports filtering because it's part of the "common parameters", but to be more in line with the cmdlets' original purposes, you should `ls` (`Get-ChildItem`) first, because it has more filtering capability, and then pipe the results to `cp`.
Is it complex? No, actually its complexity is exactly the same as that of your `find` example! `find` is more or less equivalent to `ls` in that both gathers the list of files that meet certain criteria. And then, like `find` invokes `cp` multiple times to do actual copying, `ls` (`Get-ChildItem`) feeds its result to `cp` (`Copy-Item`). They are structured in a similar way.
I'd even say the PS one-liner is more akin to "the UNIX philosophy". In the bash one-liner, there is a direct parent-child relationship between `find` and `cp`, which doesn't utilize pipes at all. Whereas the PS one-liner connects two equivalent processes (`ls` and `cp`) with a pipe. This is exactly what I'd call "small processes work together to get the job done", which is again the UNIX way.
Well yes, that's an example that's relying on the find utility, for which the equivalent in the windows world (at least for file management) is robocopy.
I guess copy-item should be smarter to be able to handle this.
Also, for what it's worth, your example in the linked post is a bit more verbose than it really needs to be. You're comparing a full-up programming language to nant there. So yeah, it's a bit more verbose there. But I bet I can come up with a counter-example where nant is a giant nightmare to get right (or requires just dropping straight to executing external commands) (There's a reason I've killed off all usage of nant years ago, and gone to powershell for build scripts)
robocopy /r $pathFrom $pathTo *.html
robocopy /r $pathFrom $pathTo *.html /xf main.js
I guess copy-item should be smarter to be able to handle this.
Also, for what it's worth, your example in the linked post is a bit more verbose than it really needs to be. You're comparing a full-up programming language to nant there. So yeah, it's a bit more verbose there. But I bet I can come up with a counter-example where nant is a giant nightmare to get right (or requires just dropping straight to executing external commands) (There's a reason I've killed off all usage of nant years ago, and gone to powershell for build scripts)
Perl scripts can be vastly more powerful than PS. Perl is a full blown general purpose programming language with a massive collection of libs and frameworks.
It is however very powerful that Perl can be used in bash pipelines. But that is also true for any Unix tool that takes I/O.
So Bash is also very powerful with the help from all its friends that can be used with pipes. Shell native.
And you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.
It is however very powerful that Perl can be used in bash pipelines. But that is also true for any Unix tool that takes I/O.
So Bash is also very powerful with the help from all its friends that can be used with pipes. Shell native.
And you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.
> Perl is a full blown general purpose programming language with a massive collection of libs and frameworks.
> So Bash is also very powerful with the help from all its friends
> you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.
All of these things are also true for Powershell. Powershell can use any .NET Assembly, and if necessary make native windows system calls too if you really want.
> So Bash is also very powerful with the help from all its friends
> you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.
All of these things are also true for Powershell. Powershell can use any .NET Assembly, and if necessary make native windows system calls too if you really want.
Haven't really touched Windows the last 5+ years but adding .NET to the mix sounds a bit complicated in relation to Bash.
Like I said above, my point was that PS lets you expose your app logic a lot easier than writing a CLI for it.
I've been dabbling with PS (using it as my primary console) but my workflow just isn't that complex, so I don't have a compelling reason to write cmdlets (yet!).
Can you recommend a good tutorial?
Can you recommend a good tutorial?
I've used MSDN docs but I wouldn't call that a tutorial :)
The msdn docs are great, it's just difficult to navigate them. Perhaps this would help? https://msdn.microsoft.com/en-us/library/dd878294(v=vs.85).a... There's tutorials in there as well, but I didn't find them very useful compared to the overview/concepts documentation.
Yeah that's what I went trough as well but usually tutorials are shorter and more to the point, this is more reference/in-depth style - I'm guessing OP was looking for something along those lines.
> the experience of using PS was superior to that of bash
As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.
As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.
For one, I can do away with all of the text parsing that is prone to breakage in case a tool changes their output somewhat (or god help me - tools that can't handle unicode properly).
The power of bash actually comes from the GNU coreutils and other userland software. It has almost very little to with bash.
Try out bash on a busybox and feel the crippled effect.
The power of bash actually comes from the GNU coreutils and other userland software. It has almost very little to with bash.
Try out bash on a busybox and feel the crippled effect.
So you mean PS as a scripting language, not as a shell, is superior. That's not a surprise, since it's newer and designed to do away with many annoyances of Bash. As a shell, however, it is sadly just slightly more usable as the REPL of, e.g., Python.
I had been a full-time Linux (desktop) user for more than 10 years, and only recently made a transition to Windows. As I'm nowhere proficient at using PowerShell I might be overrating it a bit, as the grass is always greener on the other side. Anyways, what I found to be satisfying while using PS were:
1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the UNIX philosophy, and I appreciated that when using Linux, but after using PS I started to have mixed feelings about that. When using bash/zsh, I typically used awk to extract the data I wanted from the text emitted by an external process. Doing so isn't hard, mostly as simple as using `awk {print $3}` or something like that, but it is still a bit annoyance and more importantly, vulnerable to the changes in the output format.
PS cmdlets communicate with themselves using objects, so it is very easy to extract some columns out of the command results. For example, when I query about a process in PS:
This is probably why many Linux commands have detailed options to limit displayed information. For example, `uname` has -s, -r, -m, -p, and many others that are just portions of -a. If it were in PS there would be no other options than -a and users could utilize it accordingly. Likewise `ps` has many options just to control the output which is again not necessary in the PS's side.
Also due to the probable scripts that may be reliant on the column orders (e.g. my script assumes the third column to be always the one I wanted, because I hard-coded `awk {print $3}` in there), it is very hard to change the layout of the output in Linux commands. In PS there is no layout in the first place, so this backward compatibility concern doesn't exist.
2. Command names are much clearer. Many names are pretty descriptive so I don't have to remember the exact abbreviated forms, but at the same time they provide shorter aliases. For example `Get-Process` can also be called `ps`. bash/zsh can also benefit from this by manually assisning aliases, but I believe "sane defaults" should be long-descriptive names first, and abbreviated forms later.
3. Much more objected-oriented design. Say for example you want to get the last modified date of a file. In Linux I'd use `stat` and somehow extract information from it. Or, `stat` may have some option to print mtime so I may have to google for it. In PowerShell, I can use this instead:
Not only that, but PS is much closer to a general-purpose programming language than bash/zsh. It has built-in calculations (no need to rely on expr/bc), and it even has some basic type safety, such as:
When the logic of my scripts got complicated, I tended to abandon shell scripts and start programming in Python. But after learning PowerShell I'm starting to have a confidence that typical workflows can be implemented in PowerShell, in a readable way. I even think that PS can be utilized as a general-purpose programming language, like, "Python without dependencies", because PS is installed by default on Windows nowadays.
Whoa, my response got unintentionally huge O.o. Hope this helps anyone.
1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the UNIX philosophy, and I appreciated that when using Linux, but after using PS I started to have mixed feelings about that. When using bash/zsh, I typically used awk to extract the data I wanted from the text emitted by an external process. Doing so isn't hard, mostly as simple as using `awk {print $3}` or something like that, but it is still a bit annoyance and more importantly, vulnerable to the changes in the output format.
PS cmdlets communicate with themselves using objects, so it is very easy to extract some columns out of the command results. For example, when I query about a process in PS:
PS> Get-Process -Name chrome
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
362 80 169636 109896 36,411.16 484 1 chrome
497 113 274988 132544 5,161.00 656 1 chrome
404 84 87444 55356 303.56 764 1 chrome
PS> Get-Process -Name chrome | Format-Table -Property cpu,id
CPU Id
--- --
36441.265625 484
5163.09375 656
303.5625 764
PS> ps chrome | sort cpu -descending | select -first 3
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
1186 317 1876160 1055016 88,462.64 10524 1 chrome
1023 88 1825008 668684 37,740.92 6128 1 chrome
362 80 155776 64560 36,848.00 484 1 chrome
This is probably why many Linux commands have detailed options to limit displayed information. For example, `uname` has -s, -r, -m, -p, and many others that are just portions of -a. If it were in PS there would be no other options than -a and users could utilize it accordingly. Likewise `ps` has many options just to control the output which is again not necessary in the PS's side.
Also due to the probable scripts that may be reliant on the column orders (e.g. my script assumes the third column to be always the one I wanted, because I hard-coded `awk {print $3}` in there), it is very hard to change the layout of the output in Linux commands. In PS there is no layout in the first place, so this backward compatibility concern doesn't exist.
2. Command names are much clearer. Many names are pretty descriptive so I don't have to remember the exact abbreviated forms, but at the same time they provide shorter aliases. For example `Get-Process` can also be called `ps`. bash/zsh can also benefit from this by manually assisning aliases, but I believe "sane defaults" should be long-descriptive names first, and abbreviated forms later.
3. Much more objected-oriented design. Say for example you want to get the last modified date of a file. In Linux I'd use `stat` and somehow extract information from it. Or, `stat` may have some option to print mtime so I may have to google for it. In PowerShell, I can use this instead:
$file = Get-Item C:\Windows\notepad.exe
$file.LastWriteTime
$processes = Get-Process -Name chrome
$processes[0].CPU
Not only that, but PS is much closer to a general-purpose programming language than bash/zsh. It has built-in calculations (no need to rely on expr/bc), and it even has some basic type safety, such as:
PS> 1 + 2
3
PS> 1 + "a"
Cannot convert value "a" to type "System.Int32". Error: "Input string was not in a correct format."
+ 1 + "a"
+ ~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvalidCastFromStringToInteger
When the logic of my scripts got complicated, I tended to abandon shell scripts and start programming in Python. But after learning PowerShell I'm starting to have a confidence that typical workflows can be implemented in PowerShell, in a readable way. I even think that PS can be utilized as a general-purpose programming language, like, "Python without dependencies", because PS is installed by default on Windows nowadays.
Whoa, my response got unintentionally huge O.o. Hope this helps anyone.
You seem to have articulated all my thoughts perfectly.
The thing about parsing text is a very huge pain point for me because I've had some tool change their output (and unicode issues) which broke some scripts.
The structured nature of PS makes it very powerful and allowed me to write a script that checks the latest versions of some software upstream and tells me if there are updates. I have that on bash as well but it's comparatively unmaintainable.
The thing about parsing text is a very huge pain point for me because I've had some tool change their output (and unicode issues) which broke some scripts.
The structured nature of PS makes it very powerful and allowed me to write a script that checks the latest versions of some software upstream and tells me if there are updates. I have that on bash as well but it's comparatively unmaintainable.
i agree with the fact that PS object oriented communication between commands is much better then text. But I disagree about your point (2) saying that command names are more discoverable. with linux style conventions, there is a hierarchy that helps you navigate between command's features. for example `docker image ls` you can type docker, see that there is an images subtree, type docker images, see that there is an ls command, and run it. With Powershell you kind of have to guess and type `get-docker` and tab through commands. Also some times the verb is not easy to guess. So in terms not relying on documentation as you called it, I think PS is worse.
That being sayd, once you do know the command you need, using it is much easier with PS as you nicely described. tip - if you liked tab completion, try ctrl+space :)
I was thinking more about the "proper noun" aspect of the UNIX commands. I mean, what do `awk`, `sed`, `tar`, `xargs`, `df` mean? Why does `free` only print the remaining memory, not the disk space? Why is `top` even related to processes? They are all like that because Unix has had a long way until today. In the beginning `grep` would have been enough, but suddenly someone wanted to improve the state of affairs, and made a new command named `awk`. Probably there had only been `ar`, and then later the necessity of `tar` was found. `free` is not `mf` and `df` is not `free`, because the original designer thought the free space of the main memory was more important. All these inconsistency/idiosyncrasy do make learning the UNIX command hierarchy harder. We developers don't feel that way because we all are very used to such commands, but there might be some memory in our inside when we tried really hard to memorize all of the useful commands just to do basic things.
PowerShell didn't have this backward compatibility concern so it built up its own vocabulary from the scratch. While it is nowhere near to perfect (as your example shows, the VERB-NOUN naming scheme can be a bit cumbersome when some functionalities need to be grouped), I'd say it is at least much more consistent regarding basic file/device management, because there was simply no baggage to consider when they designed PowerShell for the first time.
Ah, and thanks for suggesting `Ctrl-Space`! I thought it would have been better if PowerShell had a GUI widget listing possible candidates, so I was considering sending a patch. It turns out that the MS people are definitely more clever than me. :)
PowerShell didn't have this backward compatibility concern so it built up its own vocabulary from the scratch. While it is nowhere near to perfect (as your example shows, the VERB-NOUN naming scheme can be a bit cumbersome when some functionalities need to be grouped), I'd say it is at least much more consistent regarding basic file/device management, because there was simply no baggage to consider when they designed PowerShell for the first time.
Ah, and thanks for suggesting `Ctrl-Space`! I thought it would have been better if PowerShell had a GUI widget listing possible candidates, so I was considering sending a patch. It turns out that the MS people are definitely more clever than me. :)
I used majority of mainstream shells and Posh is a scpace ship compared to any other in existence. I wont reiterate again and again why, there are planty of places eihter on HN, reddit or SO why is it so. I guess you will have to give it a serious try.
PS is great if everything you are dealing with is built for the .NET ecosystem.
It's less great otherwise.
This makes it often great for working on Windows, and definitely great for working with Windows and other MS software that is designed for the .NET/PS world.
It's less great otherwise.
This makes it often great for working on Windows, and definitely great for working with Windows and other MS software that is designed for the .NET/PS world.
Perhaps, but I find it very easy to interact with various webservices. We use powershell to call API methods on our load balancers, change AWS configuration, change DNS records and a variety of other things.
I go back and forth between windows/unix for my day job and I also would be curious on any actual bullet points. I find that even in a situation where PS could potentially prove more useful or has an extra feature, what you end up with is a new set of chrome tabs open just to try and figure out how to do the thing.
I suppose this might(?) be mitigated if you're embedded in the .NET world, but I just can't seem to get the memory down for the silly cmdlet naming and since they also have the admittedly interesting object-piping thing going on, you're always battling two pain points at a time instead of just one (e.g. syntax/naming in bash)
I suppose this might(?) be mitigated if you're embedded in the .NET world, but I just can't seem to get the memory down for the silly cmdlet naming and since they also have the admittedly interesting object-piping thing going on, you're always battling two pain points at a time instead of just one (e.g. syntax/naming in bash)
One of the best bits of PS1 advice I've seen was to get used to the Verb-Noun naming pattern [1] and in particular, the discoverability of the very standardized set of verbs [2].
Once you can guess the verb you want, then it can often be a simple matter of finding the right noun, and often nouns will be useful in sets similar to verbs.
Get-Verb, Get-Command, and Get-Help are all quite useful for looking for a command.
For dealing with the object pipeline I tend to find ConvertTo-Json very handy because as a developer I'm already quite used to reading objects in JSON already. (ConvertFrom-Json can similarly be used to bootstrap a PS1 pipeline with test data or remote data.)
[1] https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/...
[2] https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).a...
Once you can guess the verb you want, then it can often be a simple matter of finding the right noun, and often nouns will be useful in sets similar to verbs.
Get-Verb, Get-Command, and Get-Help are all quite useful for looking for a command.
For dealing with the object pipeline I tend to find ConvertTo-Json very handy because as a developer I'm already quite used to reading objects in JSON already. (ConvertFrom-Json can similarly be used to bootstrap a PS1 pipeline with test data or remote data.)
[1] https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/...
[2] https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).a...
I've used both extensively and I think they are fairly different, with different strengths and weaknesses. Bash is more pragmatic and more concise on the command line. PS is more uniform in its design and nicer for scripting IMO. It allows passing objects through pipes, has built-in JSON reading and writing, built-in parameter handling with defaults, mandatory and optional params, switches etc., and such niceties.
Bash is not more concise, its other way around, of course, if you use default aliases. The reasons is logical - you almost never use text parsing in Posh while you almost never have anything without it in bash.
I find Powershell non intuitive to learn honestly, Bash just clicks with me way more for some reason.
PowerShell needs the .Net runtime so I doubt it will ever be on a par with cmd.exe.
cmd.exe has a limited set of builtin and relies on external applications with a plain text interface.
PowerShell has builtins, can import code from any .NET Assembly or native code DLL, invoke external processes, full featured programming language and structured data.
cmd.exe will never be on par with PowerShell.
PowerShell has builtins, can import code from any .NET Assembly or native code DLL, invoke external processes, full featured programming language and structured data.
cmd.exe will never be on par with PowerShell.
GP was replying to a comment about the performance of PS compared to cmd.exe, stating that PS could never be on par with cmd.exe because it needs to load more.
Yeah this is the one thing with PowerShell: with great power comes, erm, not so great performance. I've never been a full-time shell user so after years of occasionally getting some stuff automated using bash discovering Powershell really was like a breath of fresh air.. No more trying/failing to come up with the correct regex to parse the plain text spit out by tools. Command-line completion of arguments. A whole bunch of sane defaults and command names making things easy to discover. Etc. Now at first I only ran PS on a beefy workstation and didn't notice it was kinda slow (even for common operations). But on not-so-beefy machines: yeah, not nice. Then again, cmd is worthless in comparsion with PS so I stopped caring. Thing is also: the time gained by how fast I can get stuff done in PS probably makes up for the time lost trying to figure out the weird syntax of other shells, especially cmd.
Yeah, the new Powershell will be very fast AFAIK. They had to do it because nano server was starting faster then Posh which was ridiculous.
VSCode + TypeScript is the perfect foot-in-door for MS to get into the web space.
They're both excellent products by themselves, but also give Microsoft the platform to start dangling turnkey Azure integration in front of developers.
Imagine if the IDE started to offer the ability to configure, deploy, and manage targeted production stacks--no browser / command line hackery required. That would be compelling.
They're both excellent products by themselves, but also give Microsoft the platform to start dangling turnkey Azure integration in front of developers.
Imagine if the IDE started to offer the ability to configure, deploy, and manage targeted production stacks--no browser / command line hackery required. That would be compelling.
You can do that right now if you use Azure ARM templates and set up project-level actions to run them through the Azure CLI. It's just a matter of someone bundling it together as an extension (I've been working on one, but solely for template snippets).
VS Code's release notes are really nicely done - I don't usually comment on documentation but whoever wrote these did a bang up job!
I remarked this to my colleagues; part of me wishes they'd do faster releases, if only so that the changelog is smaller. Big lists of changes scare me. Big lists of changes that were apparently all done in a month and work without being horribly broken or half-assed, on the other hand, impress me.
This comment is a long-winded compliment.
This comment is a long-winded compliment.
Absolutely! I love to read through them on each release to discover whats new. And each time I'm surprised how many new useful things get integrated.
yeah I must say the team does a great job, I was thinking the same thing
Kudos!
VSC is an "redefined" and high hackable (largely thanks to the rich nodejs ecosystem) editing environment which you can do everything as you like. So, to pin it into an editor or an IDE makes less sense.
more technical imagination: the project lead Erich Gamma has long history works in the field of Eclipse and definitely knows the importance (and pain) of the code editing to a programmer. Then, I (and we) can expect VSC would go beyond the Eclipse and hunt the heart of coders from other IDE products some day:)
final shameless insert: recently I release an extension to provide Swift editing environment[1] to try to bring Go/Rust like experiment for Swift server side development. Now it works for both Linux and macOS.(I hope to investigate the possibility for windows 10 WSL after release 2.0 coming soon.)
[1] https://github.com/jinmingjian/sde
VSC is an "redefined" and high hackable (largely thanks to the rich nodejs ecosystem) editing environment which you can do everything as you like. So, to pin it into an editor or an IDE makes less sense.
more technical imagination: the project lead Erich Gamma has long history works in the field of Eclipse and definitely knows the importance (and pain) of the code editing to a programmer. Then, I (and we) can expect VSC would go beyond the Eclipse and hunt the heart of coders from other IDE products some day:)
final shameless insert: recently I release an extension to provide Swift editing environment[1] to try to bring Go/Rust like experiment for Swift server side development. Now it works for both Linux and macOS.(I hope to investigate the possibility for windows 10 WSL after release 2.0 coming soon.)
[1] https://github.com/jinmingjian/sde
I worked on the debug inline values feature. Let me know if you have any feedback/questions regarding that. Its currently disabled for evaluation purposes but you can enable in settings via "debug.inlineValues": true
http://code.visualstudio.com/updates/v1_9#_inline-variable-v...
http://code.visualstudio.com/updates/v1_9#_inline-variable-v...
Thanks for all your hard work on this feature, it looks great!
I am super pleased that VS Code exists, works on multiple platforms, and is apparently a first class project at MS Dev. Like some other devs, I ran as far from Microsoft as I could many years ago... but now it seems they are trying to be more open, or less protectionist/monopolistic.
I used VS Code (starting at v1.5) for a couple of projects (on my Mac), and I found it quite effective and very performant. The performance, particularly the interface latency, is a big complaint I have with other "fat" IDEs. And while my hands still try to do some Vi commands and a lot of Emacs commands, I found the keyboard options for VS Code acceptable.
This is as close to a Thank You to Microsoft that I have uttered in a long time. I hope they keep up the good work.
I used VS Code (starting at v1.5) for a couple of projects (on my Mac), and I found it quite effective and very performant. The performance, particularly the interface latency, is a big complaint I have with other "fat" IDEs. And while my hands still try to do some Vi commands and a lot of Emacs commands, I found the keyboard options for VS Code acceptable.
This is as close to a Thank You to Microsoft that I have uttered in a long time. I hope they keep up the good work.
I keep trying VSCode, but the main thing that keeps me going back to Atom is the fact that I have to do everything at the command line or by editing an enormous json file. Maybe I'm spoiled, but I'd much rather have a nice UI to deal with settings than have to figure out that, say, in order to show line numbers I have to modify "editor.lineNumbers" and set it to "on" (or is it "true"? or 1? I can't remember... let me go waste more time looking it up...)
Take another look. What you get now is still a gigantic JSON file... except it opens in a two-pane window, with the default settings (including detailed documentation in comments) on the left, and your local copy on the right. And beside each setting on the left is an icon where, if you press it, it copies the setting into your local copy, with all the correct JSON syntax. And usually there's a dropdown showing the different valid options and it uses folding to divide neatly up into sections. Oh, and the settings instantly apply when you save the file.
To me, this combines the best parts of being a text file --- standard commands, formatting the way you like it, you can search it, version controllable --- with the best parts of a GUI --- prompting as to what options are available, easy selection of alternates, documentation, etc. It's an amazingly good implementation and I wish more applications used it.
(e.g. the comment for editor.lineNumbers now tells me that valid options are 'on', 'off' and 'relative', which counts relative to the line the cursor is on.)
To me, this combines the best parts of being a text file --- standard commands, formatting the way you like it, you can search it, version controllable --- with the best parts of a GUI --- prompting as to what options are available, easy selection of alternates, documentation, etc. It's an amazingly good implementation and I wish more applications used it.
(e.g. the comment for editor.lineNumbers now tells me that valid options are 'on', 'off' and 'relative', which counts relative to the line the cursor is on.)
Two things to add:
The settings files now have intellisense in them so you don't have to lookup each option.
You can also have a separate settings.json file for that project and check it into git inside the .vscode folder and make those same settings available to your entire team.
We use that in every project and it is great.
The settings files now have intellisense in them so you don't have to lookup each option.
You can also have a separate settings.json file for that project and check it into git inside the .vscode folder and make those same settings available to your entire team.
We use that in every project and it is great.
This is preciselly the reason I and many of my collegues love it - no GUI for settings. This means you can use hundreeds of tools to manage your settings and it is in true spirit of unix philosophy to keep everything as a text file.
Much more time is wasted by looking for options in GUI equivalent and reproducibility, sharing, backup and comparing (diff) are way harder or nonexistent. Creating frontend for it is trivial, but honestly, why drop from horse to donkey as they say.
All the apps should have settings like that.
Much more time is wasted by looking for options in GUI equivalent and reproducibility, sharing, backup and comparing (diff) are way harder or nonexistent. Creating frontend for it is trivial, but honestly, why drop from horse to donkey as they say.
All the apps should have settings like that.
Yeah, like many others I maintain my configuration files in Git, so having to use files to configure is a pro, not a con, at least for me! I haven't been using VS Code but this sole factor might be the reason I will reconsider using it in the future.
Some might say having both manual configuration and automated dialog would be better, but many such interfaces ruin the structures of my intentionally organized setting files. I will take no GUI than misbehaving GUI at any time.
Some might say having both manual configuration and automated dialog would be better, but many such interfaces ruin the structures of my intentionally organized setting files. I will take no GUI than misbehaving GUI at any time.
This is one of the things I really like about VC, they just implemented their config editing largely the way they support any language: just a json-file (but with comments) which has full-blown intellisense, and offers you a complete example of the defaults side-to-side with clear examples and explanations.
It also allows you to override certain settings per project/directory, which can then easily be included in git (like files to exclude from the file view for a specific project, path/tool settings, indentation settings, ...)
It also allows you to override certain settings per project/directory, which can then easily be included in git (like files to exclude from the file view for a specific project, path/tool settings, indentation settings, ...)
To your point, Atom allows both. Don't like the UI? Just edit config.cson or whatever directly! You're not locked into it.
I just find that if I have to go through a LOT more steps without a UI.
I just find that if I have to go through a LOT more steps without a UI.
I would rather have devs invest time in serious functionality then doing stuff like GUI.
Otherwise, this quickly turns to nonsence such as Nano server image builder [1] because Microsoft is still babysitting people who CBB to spend few hours to learn Powershell basics and need a GUI that generate 1 liner script.
Microsoft should definitelly rise beyond click next culture.
[1] https://blogs.technet.microsoft.com/nanoserver/2016/10/15/in...
Otherwise, this quickly turns to nonsence such as Nano server image builder [1] because Microsoft is still babysitting people who CBB to spend few hours to learn Powershell basics and need a GUI that generate 1 liner script.
Microsoft should definitelly rise beyond click next culture.
[1] https://blogs.technet.microsoft.com/nanoserver/2016/10/15/in...
Discoverability and ease of use ARE serious functionality.
To be fair, the settings editor in VSCode shows all the settings possible in a split window with user settings, with neat categories and auto-completion. It's almost like a GUI setting dialog noways and makes it way easier to see what you have changed.
This: https://i.imgur.com/oPYr6Ch.png isn't discoverable?
The comments tell you in detail how each setting works (as you can see, they are even translated), you can search for a specific setting on the top, and it's categorized as well; defaults on the left, your own on the right.
The comments tell you in detail how each setting works (as you can see, they are even translated), you can search for a specific setting on the top, and it's categorized as well; defaults on the left, your own on the right.
There are different ways to discover stuff. Powershell itself clearly proves that it can be done on system level without any GUI whatsoever.
We had the "ease of use" in GUI paradigm for decades and it didn't hold. Why don't you give it a chance as a text ?
We had the "ease of use" in GUI paradigm for decades and it didn't hold. Why don't you give it a chance as a text ?
Why do you want to limit yourself to only one way of doing things?
Just curious, is Atom's UI considerate about modifying the content of a configuration file? I'm tired of programs changing the structure of it willy-nilly without even notifying the user (e.g. a click in the toolbar implicitly loads the configuration file and saves it with a different layout). Is Atom OK with this?
This is a problem with Sublime Text too. Don't bother putting comments in your settings file, or rearranging its contents. One hit of Ctrl-minus, even by accident, and your config file is wiped out and replaced with an auto-generated one, which incidentally contains your updated font size. You're welcome.
Seriously, Ctrl+Shift+P and start typing gets me to what I need 99% of the time, it's glorious.
Combined with the VIM plugin and I rarely need to touch the mouse.
Combined with the VIM plugin and I rarely need to touch the mouse.
I didn't try vim plugin but in general, no vim plugin is substitute for vim.
If you mostly just want the memorized shortcuts to work, they tend to work OK in VSCode, Atom, IntelliJ and even Emacs - Spacemacs is even a better ViM for some.
As someone who did a fair amount of hacking in vimL, evil-mode is a drastically improved vim. It gets basically everything right, out of the box, and extending it isnt nearly as painful as using vimL or interacting with vim's Python API.
> It gets basically everything right, out of the box
Custom bindings don't work on the default document. That's a pretty big failure right out of the box.
And I still prefer vimL to lisp, it's the php of editor extension languages. It's not great for big plugins but ok great to slap things together quickly.
Custom bindings don't work on the default document. That's a pretty big failure right out of the box.
And I still prefer vimL to lisp, it's the php of editor extension languages. It's not great for big plugins but ok great to slap things together quickly.
It doesn't, in my experience, get insert mode shortcuts like C-h right out of the box because it clashes with emacs' help mode functionality.
I don't get that mindset at all. I can see desiring a file/command line interface for settings, but to want no GUI option at all for others is just strange.
The difference back in the years of old between running a Linux Server and running a Windows Server is one was GUI based and one is text based. I prefer text based a thousand times over. GUI is fine for single use but for text files it is a simple softlink and git away from having everything the same everywhere.
I use VS Code in three locations in three different OS and I love how it works the same everywhere because I just have text files.
I use VS Code in three locations in three different OS and I love how it works the same everywhere because I just have text files.
While I agree that a real settings menu could be an improvement, they have made the settings experience better. They show a searchable annotated list of all the default settings on the left, and when you type a setting key in on the right it will show suggestions for possible values.
Looking at it just now, I also see that they added categories, and little edit buttons when you hover over a setting which allow you to click on what option you want. It's a bit strange to me that they're slowly turning a config file into a settings interface, but I guess it works fine for a Developer-focused product.
Looking at it just now, I also see that they added categories, and little edit buttons when you hover over a setting which allow you to click on what option you want. It's a bit strange to me that they're slowly turning a config file into a settings interface, but I guess it works fine for a Developer-focused product.
Well that's good to know -- in that case I'll give it another shot.
> I'd much rather have a nice UI to deal with settings than have to figure out that, say, in order to show line numbers I have to modify "editor.lineNumbers" and set it to "on" (or is it "true"? or 1? I can't remember... let me go waste more time looking it up...)
Maybe you've taken a look at it a while ago. It's still a big json file (great! everything at hand) but very easy to edit since it provides a lot of assistance: there's icons to set a new option, references for everything, and intellisense/autocompletion for the schema of every option you want to change. It'll even show invalid options with a squiggle (e.g. when some setting becomes deprecated).
IMO it's the best way to have settings in an app, especially when you can install extensions that adds settings of their own or when you want settings to be version-controllable.
Maybe you've taken a look at it a while ago. It's still a big json file (great! everything at hand) but very easy to edit since it provides a lot of assistance: there's icons to set a new option, references for everything, and intellisense/autocompletion for the schema of every option you want to change. It'll even show invalid options with a squiggle (e.g. when some setting becomes deprecated).
IMO it's the best way to have settings in an app, especially when you can install extensions that adds settings of their own or when you want settings to be version-controllable.
well, it's an editor for programming. those tools are usually all about typing text, automatically completing text, and validating text. appling those idea to a json config file shouldn't be allien to a programmer.
I use fancy autocompleting and validating text editor for exactly that reason - remembering if it's "on" or "true" or "yes" is too much overhead.
So yeah, json or (preferably) any other markup for settings is fine so long as it hints me with possible values as I type, tooltips each variable with its meaning and so on.
So yeah, json or (preferably) any other markup for settings is fine so long as it hints me with possible values as I type, tooltips each variable with its meaning and so on.
> so long as it hints me with possible values as I type, tooltips each variable with its meaning and so on.
VSCode does this and more. See sibling comments.
VSCode does this and more. See sibling comments.
How often do you change these settings, though? I choose VSCode for the performance and great addons.
I share your opinion on the settings and command line. While I like it to loads faster than full fledged Visual Studio, in a year or so of using it on Mac OS I still doesn't use even 1% of its features because they are not _discoverable_ at all. Modifying or doing anything beyond text editing require googling. The same apply for using langages extensions beyond syntax coloring. Even Intellisense does not works as expected out of the box so I don't use it.
> still doesn't use even 1% of its features because they are not _discoverable_ at all.
There are now categories in the settings file, a search bar and auto-completion, which should make discovery easier.
> The same apply for using langages extensions beyond syntax coloring.
Do you mean to say that extensions at https://marketplace.visualstudio.com/VSCode are hard for you to discover or that too much of your required functionality is in extensions?
> Even Intellisense does not works as expected out of the box so I don't use it.
If you have found a bug, it would be great to report it at https://github.com/Microsoft/vscode/issues
There are now categories in the settings file, a search bar and auto-completion, which should make discovery easier.
> The same apply for using langages extensions beyond syntax coloring.
Do you mean to say that extensions at https://marketplace.visualstudio.com/VSCode are hard for you to discover or that too much of your required functionality is in extensions?
> Even Intellisense does not works as expected out of the box so I don't use it.
If you have found a bug, it would be great to report it at https://github.com/Microsoft/vscode/issues
I use vs code for Go development and it's pretty amazing. Slowly starting to use it in other languages as well, but the Go support is really 5*.
I use it for F# and Nim and while there are some flaws, it's the best experience on linux for these two languages. It also lowers the bar to entry on other languages, e.g. Go, which is on my list of to-learns.
How do you like working with Go? I've been meaning to start trying it out here soon, but haven't looked very far. I'm coming from a C# background.
I come from C#. Golang is nice and simple. I really miss generics. Going from the expressiveness of C# to golang is hard at first.
If you come from a C# background, it will feel a bit weird initially. You will more than likely miss generics, you might also miss the strong OOP model.
In the compiled world, I have somewhat of a background in C (haven't really done much with it in the last few years, though), so to me Go feels sort of like "C with a really strong std lib". I have really enjoyed the decisions they have made with the language, tbh, the people behind it have a proven track record. It's fun and very powerful, there is tremendous potential in it.
I miss all the libs available in C, but this is understandable due to the early age of the project. I also feel like it needs better package management (but I read that is a priority for this year).
In the compiled world, I have somewhat of a background in C (haven't really done much with it in the last few years, though), so to me Go feels sort of like "C with a really strong std lib". I have really enjoyed the decisions they have made with the language, tbh, the people behind it have a proven track record. It's fun and very powerful, there is tremendous potential in it.
I miss all the libs available in C, but this is understandable due to the early age of the project. I also feel like it needs better package management (but I read that is a priority for this year).
I have a new project at work that I decided to use it for to see how I liked using VS Code.
For the most part, I like it, but it's lack of Mac-nativeness bugs me, and it may bug me enough to switch. Double clicking the window bar in all natives app minimizes them to the dock for me. In Visual Studio, it maximizes my window (but not into full screen mode). I keep clicking the menu bar to minimize a window, and this keeps happening. It's kind of maddening.
For the most part, I like it, but it's lack of Mac-nativeness bugs me, and it may bug me enough to switch. Double clicking the window bar in all natives app minimizes them to the dock for me. In Visual Studio, it maximizes my window (but not into full screen mode). I keep clicking the menu bar to minimize a window, and this keeps happening. It's kind of maddening.
There is a way to set VScode to use the native menu bar on macOS instead of the Electron'd frameless bar.
Enabling that system-wide made the experience so much more pleasant:
"window.titleBarStyle": "native",OMG this is so much better. I don't get why they would make "custom" the default setting. Thank you.
[deleted]
[deleted]
I never minimize anything on Mac, the concept is not so useful since there's nothing interesting on the "desktop" anyway.
I keep a lot of different overlapping windows open, and I sometimes minimize apps to find other stuff, not the desktop. For instance, I might be minimizing my text editor so that I can push a bunch of Git changes in Tower.
It looks pretty bad on Linux too. Somehow they managed to transport the crappy font rendering from Windows to Linux. It really feels like it's not built for Linux, but just shoe-horned in.
On Linux, it renders fonts the same way Chromium or Chrome do. If you're getting "crappy font rendering from Windows", you probably need to change your fonts.conf to change font hinting from full to slight (or none, if you like it more like Macs).
Edit: And also note that, for whatever reason, GNOME does its own thing where you also have to edit the GSettings in addition to the fonts.conf settings depending on what app you're running.
Edit: And also note that, for whatever reason, GNOME does its own thing where you also have to edit the GSettings in addition to the fonts.conf settings depending on what app you're running.
Font rendering is handled by Chromium's libraries/dependencies.
Do you also criticize Chromium's font rendering? Maybe you are just looking for things to complain about?
Do you also criticize Chromium's font rendering? Maybe you are just looking for things to complain about?
Chromium font rendering on Windows is terrible as it doesn't properly use the platform renderer and settings.
However on Linux it does, so this sounds like a broken fontconfig setup, or a toolkit not getting the right hinting config.
However on Linux it does, so this sounds like a broken fontconfig setup, or a toolkit not getting the right hinting config.
I'm using it on Windows and Linux, and found it pretty good. What's the issue with fonts?
I work on Chromium and I test every VS Code version to see how it performs with the Chromium source code (except third_party). This is the first time I'm impressed. My observations:
1. Go to file is a little bit slower than Sublime Text but the extra features in VS Code make that tradeoff worthwhile. 2. The C/C++ extension enables go to definition/header without any extra configuration. 3. I like that it runs on top of Electron which is after all a fork of Chromium. 4. I haven't tried the debugger yet but I'm hopeful that will work fine too.
I'll keep playing around with it and maybe even switch from Sublime Text.
1. Go to file is a little bit slower than Sublime Text but the extra features in VS Code make that tradeoff worthwhile. 2. The C/C++ extension enables go to definition/header without any extra configuration. 3. I like that it runs on top of Electron which is after all a fork of Chromium. 4. I haven't tried the debugger yet but I'm hopeful that will work fine too.
I'll keep playing around with it and maybe even switch from Sublime Text.
I was a die hard ST3 user and Microsoft hater and I begrudgingly gave VS Code a shot after a dev I respected gave it a shout out on twitter. After a day of heavy use it became my daily driver. It is a great balance of speed, configurability, and features. Very impressed and highly recommend giving it a shot. Its just getting better and better.
It's nicer than Atom and almost feels as snappy as Sublime. But Vim still is miles better when you have put in the work to become proficient. MacVim works great for retina screens and high color support.
The VIM emulation plugin actually works reasonably well.
I know but it's not Vim.. I have been using VScode for the past 6 months and it was a relief to get back to Vim. Productivity skyrocketed since I am not constantly trying new plugins, wrestling with not knowing the IDE well enough, hard wired Vim/terminal brain etc.
And just small stuff that is not working or works another way quickly gets very annoying.
I use more than basic editing.
And just small stuff that is not working or works another way quickly gets very annoying.
I use more than basic editing.
I'm probably going to try VScode again but it was not there yet for me. Also please bring in full Perl support please!
[deleted]
The same is true for Neovim (and Vim 8?) in the terminal too.
As an emacs user, it's interesting to watch the race of open source extensible editors like Atom and VSCode.
I still haven't been tempted to leave emacs, but it's great to see so much progress in the ecosystem.
I still haven't been tempted to leave emacs, but it's great to see so much progress in the ecosystem.
Given that this runs on electron, which is basically a web browser with a node backend, is it possible to run this either as a webserver or otherwise remotely ?
I'd like to run this with the webserver running on a big dev machine at work and the client at work. X forwarding is not working well for me at least.
I'd like to run this with the webserver running on a big dev machine at work and the client at work. X forwarding is not working well for me at least.
I use sshfs for that. `sshfs username@remoteserver:/directory/to/mount mount_point` lets me edit the remote files locally. Then I compile and run (via mosh, which is like ssh but better, particularly if you have crappy internet) on remoteserver.
Anyone know if the C# plugin supports cshtml files yet? The lack of autocomplete, inspections and so on really hampers web development with it.
I've now switched entirely to using Rider because of this. While it's still early days for Rider (and it makes my Laptop's fans spin nonstop), being able to hastily edit my views makes it more than worth it.
(And integrated ReSharper is always good!)
I've now switched entirely to using Rider because of this. While it's still early days for Rider (and it makes my Laptop's fans spin nonstop), being able to hastily edit my views makes it more than worth it.
(And integrated ReSharper is always good!)
The slowness shown in the pre-1.9 terminal is a bit ridiculous. Was it really the case? I've never seen such a strangely-behaving emulator! Really good that they resolved the issue.
Hi, I worked on those improvements. Yes that is indeed what would happen when you ran a command with heaps of output, it would also lock up the UI while doing it. You probably haven't observed it much as you don't do recursive directory walk on a large directory ;)
You can read more about the specifics if you're interested in https://github.com/Microsoft/vscode/issues/17875
You can read more about the specifics if you're interested in https://github.com/Microsoft/vscode/issues/17875
The gained performance in the current release (and in Insiders for the past days) is huge - even without heaps of output. Those couple of milliseconds improved rendering time matter even if you "only" ls in a directory.
Thumbs up for this, Daniel. Thanks.
Thumbs up for this, Daniel. Thanks.
Hey, just wanted to say thanks for working on VS Code, I use it every day, love it!
Great, I didn't know the terminal portion if VS Code exists as a separate project. Was it made to fuel VS Code? Or did it already exist before launching VS Code?
I also liked the name of the project, xterm.js. :)
I also liked the name of the project, xterm.js. :)
It already existed, you can see when we started shipping the integrated terminal pretty clearly from the contribution graph :) https://github.com/sourcelair/xterm.js/graphs/contributors
The project itself is a fork of the popular term.js which is now unmaintained, we've taken it quite far since then. Hyper are probably going to be making a switch once a few more kinks are worked out too https://github.com/zeit/hyper/issues/1275
The project itself is a fork of the popular term.js which is now unmaintained, we've taken it quite far since then. Hyper are probably going to be making a switch once a few more kinks are worked out too https://github.com/zeit/hyper/issues/1275
Looks like xterm.js was started by Sourcelair, which looks like a Cloud IDE.
Thanks for your work on this! The addition and consistent improvement of the integrated terminal is the number one reason why VSCode is my daily driver.
Thanks for working on this!
Yeah, that was the main reason I didn't use it a lot actually. Powershell is slow to begin with and in VSC it was just 10x slower and buggy.
I am very happy that this is solved.
I am very happy that this is solved.
It was noticeable, but only really bad in some very specific cases (disk I/O?).
Ohhhh I love the new 'Synchonized Markdown" feature. This will in the end replace the need for iA writer (that I happily paid for) on my machine. As I do have a workflow already setup to (Semi-)automate creation of files from .md I now can do this inside VSC and do not need to open another application.
Thanks for bringing this feature up.. I had no idea the markdown preview feature even existed!
Alternatively I have been using IntelliJ with the Go plugin for about a year and now the Gogland EAP.
It has some really cool features like VCS integration, "TODO" panel and "goto" functionality that works through interfaces. You can "Goto Super Method" to jump to the definition of an interface function that the highlighted function implements. You can also do the reverse which is to list all the structs that implement an interface, or a specific interface function.
It has some really cool features like VCS integration, "TODO" panel and "goto" functionality that works through interfaces. You can "Goto Super Method" to jump to the definition of an interface function that the highlighted function implements. You can also do the reverse which is to list all the structs that implement an interface, or a specific interface function.
I'm critical of Microsoft and everything related to it, but I'm impressed with the whole VS Code project.
The team makes very sane development decisions. Code offers a great UI, is fast and configurable. Bugs and issues are handled quickly and despite already having overtaken all other editors IMHO, there's a constant stream of improvements that are documented nicely with every update.
Good job.
The team makes very sane development decisions. Code offers a great UI, is fast and configurable. Bugs and issues are handled quickly and despite already having overtaken all other editors IMHO, there's a constant stream of improvements that are documented nicely with every update.
Good job.
Their Workbench related changes in this release are great.
Pay attention to redone (also faster!!) terminal support.
https://code.visualstudio.com/updates/v1_9#_workbench
https://code.visualstudio.com/updates/v1_9#_workbench
I feel so guilty using this because I did not renew my license for Webstorm. I used to love webstorm but the javascript development environment/ecosystem has come such a long way since when I first purchased Webstorm.
I used to use PHP Webstorm. Its lightning fast search is awesome, but it slows to a crawl for large codebases.
This version introduced a non-trivial bug for me; When I open a file to edit through nautilus, it opens in a new window instead of reusing the existing one.
The new settings (window.openFilesInNewWindow and window.openFoldersInNewWindow) don't help no matter what when I set them to 'off'
EDIT: Fixed it on Ubuntu by removing the '--new-window-if-not-first' argument from the code.desktop related command.
The new settings (window.openFilesInNewWindow and window.openFoldersInNewWindow) don't help no matter what when I set them to 'off'
EDIT: Fixed it on Ubuntu by removing the '--new-window-if-not-first' argument from the code.desktop related command.
sudo nano /usr/share/applications/code.desktop
# set: Exec=/usr/share/code/code %UThanks for pointing this out, expect a fix to come soon in the recovery build. https://github.com/Microsoft/vscode/issues/19775
[deleted]
Anyone knows if there's something like Goya for Vim for VSCode? I know there's full screen and zen modes, but I miss margins so that when I'm full screen I can have everything centred on monitor.
I've been gradually finding myself using vscode over atom more and more, but the thing I consistently miss are Sublime-like shortcuts like Ctrl+D to duplicate a line or Ctrl+Click to add a cursor.
It's an extra key press, but ctrl-c copies the current line if there's no selection; then ctrl-v pastes it in front of the next line.
Alt-click adds a cursor. :)
Also, alt-up/down adds cursors above or below the current cursors.
Alt-click adds a cursor. :)
Also, alt-up/down adds cursors above or below the current cursors.
you're a lifesaver, kind stranger
It has a lot of shortcuts for features that are just not set by result. Take a look at the keyboard shortcut file and search for something, or install one of the templates that mimic other editors.
How to do search within search? E.g. I look in my src/ for json, but I get 50 results. In Sublime the result is a file so I can cmd+F it. Not sure how to do it here though.
Might be interesting to see a case study from this team, their engineering practices, etc. They seem to be remarkably productive and successful and to iterate quickly.
Great release and awesome release notes, as always. Many thanks to the team for such a great editor!
I'm especially thrilled by the integrated terminal improvements.
I'm especially thrilled by the integrated terminal improvements.
I really like VS Code, and try to use it as much as possible, but I can't make it my main driver until they've added more detailed theming support. Textmate themes aren't good enough. I can't get used to such basic highlighting that doesn't even come close to ReSharper's with "Color identifiers" enabled.
Man, I'd really like if they'd just add a default hotkey for 'Open Folder'. I know you can custom map hotkeys, but for an editor that's supposed to be 'easy to use out of the box', it's still lacking some basic features.
That being said, it's nice that they're improving it still
That being said, it's nice that they're improving it still
Hitting F1 for the command palette tells me that the default shortcut for Open Folder is Ctrl+K Ctrl+O
Even better, Open Recent is Ctrl+R which is handy enough I might remember it.
Huh, I guess it just isn't shown on the file menu then. Thanks!
I am really loving VS Code. However, there are 2 big things I really need to give up Brackets/WebStorm entirely.
1) Jump to definition for plain JS. Both Brackets and WebStorm can find method definitions for any JS project.
2) Multiline searches. I use this quite a lot to find files that contain 2 terms on different lines.
1) Jump to definition for plain JS. Both Brackets and WebStorm can find method definitions for any JS project.
2) Multiline searches. I use this quite a lot to find files that contain 2 terms on different lines.
1) I can already do this, just hold down control or command then hover over the symbol?
Doesn't work for any of my JS projects. However, Brackets and WebStorm work just fine.
It does work for my TypeScript projects.
Edit: It does work on some symbols in JS projects. But it doesn't work on function calls. Example: 'object.methodName()' I can't click on methodName and have it find the source. Brackets and WebStorm find all possible definitions, if there is only 1, it will take you directly there, if there are multiple, then you get a list to choose from
Edit: It does work on some symbols in JS projects. But it doesn't work on function calls. Example: 'object.methodName()' I can't click on methodName and have it find the source. Brackets and WebStorm find all possible definitions, if there is only 1, it will take you directly there, if there are multiple, then you get a list to choose from
Does anybody know a way to have better window management in VSCode? I really don't like to split always and use the mouse to drag and drop... often I use two panes and I want to duplicate view in them. Hoping for something like the Sublime Origami plugin (which was perfect for me).
Check the shortcuts. There's a lot of shortcuts to manipulate the tabs.
I am really hopeful for the enhanced scrollbar to be implemented soon. After that, I am pretty well set with vscode.
https://github.com/Microsoft/vscode/issues/4865
https://github.com/Microsoft/vscode/issues/4865
[deleted]
Can anybody explain how I can get a `jump to function defintions` when working with PHP files ? (defintions might be in included files)
This is the one thing I'd really like to figure out (be it out of the box or with a plugin).
This is the one thing I'd really like to figure out (be it out of the box or with a plugin).
"Format on Paste" could convert me from Coda, but it doesn't seem to work. macOS, HTML mode, enabled the option, restarted, doesn't format until I manually execute the Format Document command.
That's most likely because the html formatter doesn't support to format range/selection but only the full document.
[deleted]
The problem that I have with VSC releases is that they are automatic, and I don't want to screw up my current workflow when I reset the application for an update. I have wasted hours before with VSC updates.
You can set "update.channel" : "none" in your User Settings. (I was also bitten by it once)
You have an option to disable automatic VSC update. You can also update it via chocolatey.
I'm used to being able to run my program via command-R or some other key equivalent. I haven't been able to find a way to do this conveniently from VSCode. How do other VSCode users run their programs?
The Tasks system in VSCode is quite powerful: https://code.visualstudio.com/Docs/editor/tasks
Also, the integrated Terminal (Ctrl+`) is more useful with each version.
Also, the integrated Terminal (Ctrl+`) is more useful with each version.
How do you (personally) use tasks? Do you bind a key to the "Run Task" command and then type the task name in? Doesn't that feel inefficient?
I'm just trying to get the edit/build/run cycle down. So far the "run" part is missing for me.
I'm just trying to get the edit/build/run cycle down. So far the "run" part is missing for me.
It varies on the language/project. I tend to set my Build Task (Ctrl+Shift+B) to the most useful task and F1 > Run task my way to the others. That doesn't feel much more inefficient than switching to an external terminal (though as the internal terminal with Ctrl+` gets better I may start using it more often).
The F5 debug support is great in Node and .NET Core and there are extensions to support other language debugging. (I've heard the Go and Rust ones in particular are great, though I don't work in either language myself.)
The F5 debug support is great in Node and .NET Core and there are extensions to support other language debugging. (I've heard the Go and Rust ones in particular are great, though I don't work in either language myself.)
Apart from the built in task runner system, you can always use an extension that does a "classic" command-R.
I use https://marketplace.visualstudio.com/items?itemName=formulah... and bound it to exactly this key.
I use https://marketplace.visualstudio.com/items?itemName=formulah... and bound it to exactly this key.
F5 is the default but you can set your own keyboard shortcuts from the File->Preferences->Keyboard Shortcuts menu
There appears to be no way to bind a keyboard shortcut for running an arbitrary task. https://github.com/Microsoft/vscode/issues/6550
By default F5 is "continue debugging," but debugging is limited to Node, so I don't think that's what I want.
Incidentally my MBP has no F5 key :)
By default F5 is "continue debugging," but debugging is limited to Node, so I don't think that's what I want.
Incidentally my MBP has no F5 key :)
There are debugging extensions for environments beyond Node.
Also, Ctrl+Shift+B is the default shortcut for whatever arbitrary task you have set as your Build Task in .vscode/tasks.json.
Also, Ctrl+Shift+B is the default shortcut for whatever arbitrary task you have set as your Build Task in .vscode/tasks.json.
There are debug adapters for tons of languages available through extensions. I use the C++ and Python debuggers regularly and love them :)
It's nice that they added an option to change the side of the close button. But way more important are sensible defaults, and that should be on the left side for mac os.
Still I am a very happy user of Visual Studio Code.
Still I am a very happy user of Visual Studio Code.
I was just thinking how much of a pain it was to switch from the output pane to the debug console, so I like the new tabs.
Unfortunately, I can't seem to run my launch task in my second window anymore...
Unfortunately, I can't seem to run my launch task in my second window anymore...
For about a year it has been my favorite editor when writing in Go and pretty much anything that's not Java.
I think the team behind it has been doing fantastic work. Thank you guys.
I think the team behind it has been doing fantastic work. Thank you guys.
[deleted]
Am I alone in rejecting this new wave of Electron/node-webkit based text editors? Every single one I've tried has been horribly slow, unstable, and a giant resource hog. I gave Atom a shot, and it crashed on importing a .csv file of a few thousand lines. What I want from a text editor is simply that: a text editor. For anything more advanced, move up to a proper IDE. Why anyone uses these over something like Sublime or NP++ blows me away.
My main laptop broke down and I'm currently using a Pentium Dual Core T3200, 3GB of RAM, an HDD... in other words, a pretty damn old laptop.
I knew VSCode was very optimized for an Electron application, but you have no idea how fast this is. This is faster than my Vim set-up, and I have taken my sweet time making sure Vim only loads the plugins it strictly needs and I try to switch to the asynchronous version of a plugin as soon as it pops up but still, VSCode is more consistently responsive for a lot of tasks.
I'm not sure wether I'll make a full switch yet, specially once I get a proper computer back, but the quality of the plugin ecosystem (I thought vim-go was amazing, but VSCode's Go plugin is just ridiculously good and properly asynchronous) coupled with this huge performance surprise are really making me consider it.
I knew VSCode was very optimized for an Electron application, but you have no idea how fast this is. This is faster than my Vim set-up, and I have taken my sweet time making sure Vim only loads the plugins it strictly needs and I try to switch to the asynchronous version of a plugin as soon as it pops up but still, VSCode is more consistently responsive for a lot of tasks.
I'm not sure wether I'll make a full switch yet, specially once I get a proper computer back, but the quality of the plugin ecosystem (I thought vim-go was amazing, but VSCode's Go plugin is just ridiculously good and properly asynchronous) coupled with this huge performance surprise are really making me consider it.
Comparing atom and vscode is like comparing apples to oranges. They are sharing only Electron and nothing else. Some people do not want a full blown IDE (all of them are slower than VSCode) but also do not want a bare naked editor... I tried getting Sublime as feature rich as VSCode + one python plugin. Sublime was loosing and using most of the time more resources (Anaconda plugin)... code completion, auto suggestion, method jumping, inline help... everything was better in VSCode. Also not to mention the amount of help in other languages like JS. But if I would handle really big files without logic I would probably stick more to sublime.
Depends on what features are important to you.
On my system, the new parallel file search from VS Code is an order of magnitude faster than Sublime. For example, searching my entire project is 2 secs in VS Code vs 20 sec in Sublime
On my system, the new parallel file search from VS Code is an order of magnitude faster than Sublime. For example, searching my entire project is 2 secs in VS Code vs 20 sec in Sublime
I use Atom over Sublime simply because Sublime doesn't support touch screen scrolling, and it's just second nature for me to touch and drag my screen when scrolling now.
VSCode is apparently faster than Atom, and I sped Atom up considerably by disabling languages that I rarely/never use. Timecop plugin does wonders for tracking down the slow plugins
VSCode is apparently faster than Atom, and I sped Atom up considerably by disabling languages that I rarely/never use. Timecop plugin does wonders for tracking down the slow plugins
I hope it could support gdb remote debugging
[deleted]
For those of you who use VS Code,
how fast is it when grepping large number of files? Is it at least comparable to Sublime Text?
how fast is it when grepping large number of files? Is it at least comparable to Sublime Text?
Can't compare to Sublime myself, but the global search got some major overhaul and is doing parallel searches since the last release (1.8). Can't complain about the speed.
I have no idea about Sublime Text but find-symbol for example is slow. Maybe they should take a good look at ripgrep.
I find it kind of funny that most screenshots are taken from MacOS :)
Would be great if they implement Brackets Live preview mode.
[deleted]
still no portable mode? :(
You could try via command args:
https://github.com/Microsoft/vscode/issues/329#issuecomment-...
https://github.com/Microsoft/vscode/issues/329#issuecomment-...
While it won't make VSCode portable would something like the Settings Sync plugin help?
testUser69(2)
whyileft(5)
Waiting for the rollback update. ;-)
Downvoted to oblivion, but I totally called it!!! 1.9.1 recovery build out today.
The Microsoft-developed Go plugin makes it the best Go IDE out there, the devs, (Ramya Rao etc.) are super responsive and really trying to resolve issues quickly.
If you haven't tried it yet, I think you really should and if you have found a problem, open an issue at https://github.com/Microsoft/vscode so the devs know about it, complaining doesn't help making it better. They generally release every month, so it will get fixed sooner rather than later.
P.S. Kudos to the team & contributors for another awesome release!