VS Code Roadmap 2018(github.com)
github.com
VS Code Roadmap 2018
https://github.com/Microsoft/vscode/wiki/Roadmap
235 コメント
> what's the business model behind it's development. I'm too much of a skeptic to believe it's just so developers have a warm fuzzy feeling associated with Microsoft
There are a couple things others touch on, but to expand on a few things:
1. Microsoft was formed for developers in the first place. It's first product was BASIC (for MOS 6502). Developer productivity has always been a part of Microsoft's long term vision of itself. It is entirely possible for VSCode to be developed solely to give developers warm fuzzies and for that to fit Microsoft's long term vision.
2. VSCode gently encourages you to explore other Microsoft tools and services. It's built in Typescript and makes cross-platform .NET a reality and has some useful Azure integration extensions to help you run things on Azure services. Part of the delight to VSCode is that it doesn't hard sell any of those: it offers them as opt-in tools and lets you explore them yourself. (Opinion: This is a wonderful sort of return to confidence from Microsoft that their developer tools nearly sell themselves on their own merits, Microsoft doesn't need to hard sell them.)
3. VSCode is "made out of Azure". Part of why VSCode has seemed so effortless to build was that a lot of the core pieces (particularly the Monaco code editor at the heart of VSCode was built for Azure, then reused by IE/Edge Dev Tools, VSTS, before being brought into its own in VSCode) were built for Azure itself to provide a nice development/devops environment experience in the cloud. That seems a pretty good advertisement for something like Azure when even the systems built to support the services offered are strong development tools of their own merit.
There are a couple things others touch on, but to expand on a few things:
1. Microsoft was formed for developers in the first place. It's first product was BASIC (for MOS 6502). Developer productivity has always been a part of Microsoft's long term vision of itself. It is entirely possible for VSCode to be developed solely to give developers warm fuzzies and for that to fit Microsoft's long term vision.
2. VSCode gently encourages you to explore other Microsoft tools and services. It's built in Typescript and makes cross-platform .NET a reality and has some useful Azure integration extensions to help you run things on Azure services. Part of the delight to VSCode is that it doesn't hard sell any of those: it offers them as opt-in tools and lets you explore them yourself. (Opinion: This is a wonderful sort of return to confidence from Microsoft that their developer tools nearly sell themselves on their own merits, Microsoft doesn't need to hard sell them.)
3. VSCode is "made out of Azure". Part of why VSCode has seemed so effortless to build was that a lot of the core pieces (particularly the Monaco code editor at the heart of VSCode was built for Azure, then reused by IE/Edge Dev Tools, VSTS, before being brought into its own in VSCode) were built for Azure itself to provide a nice development/devops environment experience in the cloud. That seems a pretty good advertisement for something like Azure when even the systems built to support the services offered are strong development tools of their own merit.
Minor correction, the first BASIC was for the MITS Altair 8800 which had an Intel 8080 CPU.
Minor correction, the first BASIC was for the GE-235. The Altair was the first home computer to have a version of BASIC, but BASIC had already been around for a decade before it was ported over.
https://en.m.wikipedia.org/wiki/GE-200_series
https://en.m.wikipedia.org/wiki/BASIC
https://en.m.wikipedia.org/wiki/GE-200_series
https://en.m.wikipedia.org/wiki/BASIC
Meant the first MS Basic :)
[deleted]
It's about getting developers back on the MS platform.
e.g. if VS Code and the idea of MS supporting OSS was around 5 years ago, perhaps Windows phone might have had enough apps and been successful.
e.g. if VS Code and the idea of MS supporting OSS was around 5 years ago, perhaps Windows phone might have had enough apps and been successful.
To extend on that, dotnetcore is dead in the water without a decent and supported cross-platform development experience. Visual Studio and vsmac get the job done for now, but for the long run they need something that also works on linux and is consistent across all three platforms.
Actually the C# plugin for VisualStudio Code does an amazing job supporting .NET Core (on any platform).
I stopped using VisualStudio in favor of Code in regards of .NET Core development.
I stopped using VisualStudio in favor of Code in regards of .NET Core development.
I think bunder's point is that VSCode is the "something that also works on linux and is consistent across all three platforms".
Thanks. Yeah, that was my point exactly.
Oh. Yes. Agree, it can be read like that :)
VSCode and the dotnet cli tooling fill this role on Linux. The tools are consistent across all three platforms.
I've had no end of trouble using .NET on Linux in the past couple of years. Most of my existing projects are broken, too.
Were you using Mono or .NET Core/Standard?
Both at different times. My Mono projects started breaking and getting .NET Core/Standard running on anything but their blessed distros is difficult.
> some don't like the electron-based thing/performance
It's mostly not liking Electron-based, performance is very reasonable for VSCode, I think.
As for the end-game: it's most likely luring you into Azure. Tight integration with a proper editor/IDE might give it an edge over competitors.
It's mostly not liking Electron-based, performance is very reasonable for VSCode, I think.
As for the end-game: it's most likely luring you into Azure. Tight integration with a proper editor/IDE might give it an edge over competitors.
One very specific performance metric is startup time, and Sublime beats the pants off VSCode in that department. Creating new top-level windows in VSCode is also annoyingly slow compared to Sublime (presumably because it's spinning up a new browser context). Other than that, it seems snappy enough.
YMMV I suppose, but I’ve never noticed the startup times, and I frequently create/close windows (I often have 2-3 at a time).
I just started visual studio code on my workstation, and it took 9 seconds to display a window, followed by 2 more seconds before populating it with an empty document. Sublime was sub second startup
I've always had sub second startup times. With text rendered within the first 1.5-2 at most. Time to "Actual interactivity" usually takes around 3-5 seconds, but that's mostly due to my plugins. I could start typing per-se, just not in Vim mode.
I mostly leave the editor permanently open on the project I'm working on, so I guess I don't really notice it much either way. And using the integrated terminal to change one dir back and switch to another project, then opening it with code . is a pretty good flow so I don't feel stifled in that sense either.
I mostly leave the editor permanently open on the project I'm working on, so I guess I don't really notice it much either way. And using the integrated terminal to change one dir back and switch to another project, then opening it with code . is a pretty good flow so I don't feel stifled in that sense either.
> I mostly leave the editor permanently open on the project I'm working on
I leave Visual Studio permanently open, but I use sublime for quick edits/viewing/changes (e.g. opening a remote file on perforce, or modifying a config file), so even 2 seconds to interactivity is just too long.
I leave Visual Studio permanently open, but I use sublime for quick edits/viewing/changes (e.g. opening a remote file on perforce, or modifying a config file), so even 2 seconds to interactivity is just too long.
My low-end MacBook opens it in less than 2 seconds.
I've just tried it on a gaming PC (i7, installed on an NVM SSD.) 4 second startup compared to instant for Sublime.
Even still 2 seconds is too long for quick edits.
Even still 2 seconds is too long for quick edits.
Seems it checks for updates every once in a while. Took 6 seconds the first time with network activity. Second time it was <2 seconds.
Never tried Sublime (it sounds fantastic), but VSCode is lightning fast compared to the other IDEs I currently use or have used in the past: Eclipse, IntelliJ, Visual Studio, and MonoDevelop.
IntelliJ is probably the most annoying...it takes less time than VS does, but during the 2 minutes it takes to start it hijacks the OS window focus at least 5 times. I like to actually work on other things while waiting for that beast to start up and it constantly screws everything up.
IntelliJ is probably the most annoying...it takes less time than VS does, but during the 2 minutes it takes to start it hijacks the OS window focus at least 5 times. I like to actually work on other things while waiting for that beast to start up and it constantly screws everything up.
Sure, Sublime is practically instant whereas VSCode takes... maybe slightly more than half a second on my machine.
It’s noticeable but is it really that much of an issue?
It’s noticeable but is it really that much of an issue?
Opening big files, opening lots of files, doing search and replace in open files, and my favourite, use thousands of parallel cursors to thousands of simultaneous edits in a single file, they are all noticeable slower in VSCode.
Damn, I love me them multiple cursors.
Damn, I love me them multiple cursors.
Never done thousands (wtf are you doing??) but I’ve done dozens and it’s been instant in VSCode.
Define large too - several mb? Or several 100?
Maybe you’re just an outlier?
Define large too - several mb? Or several 100?
Maybe you’re just an outlier?
It's more noticeable on some peoples machines/setups, and some people are more sensitive to this type of performance.
I'll give you that, startup time could be better. I don't really consider that much of a problem, but I can see how people would disagree.
I just opened a new window with 9 file tabs, and it opened in 3 seconds. I'm using a 2012 quad i5 desktop with non SSD drives. I suspect with SSD, it will be 1-2 seconds.
For some reason people still consider startup time a metric worth paying attention to
I use VS Code most of the time, but the reason I always use Notepad for taking quick notes _is_ the startup time of VS Code. If they improved it, I'd be using it for both. It is an important metric for some.
If I need to take a quick look at a file but don't plan on actively doing a bunch of work on it, I usually open in Sublime for the same reason.
Still get syntax highlighting and everything, but waiting for VS Code can be long enough to derail my train of thought.
Still get syntax highlighting and everything, but waiting for VS Code can be long enough to derail my train of thought.
[deleted]
I work in IntelliJ IDEA whise startup times are horrible. However, since I always work on a set of projects, I never close them, so, essentially, startup time is 0.
Also, IDEA has scratch files for quick notes available through a shortcut (I guess VS Code might have a similar plugin), so startup tome isn’t an issue either.
Also, IDEA has scratch files for quick notes available through a shortcut (I guess VS Code might have a similar plugin), so startup tome isn’t an issue either.
Engineers like to optimize everything, including how they use their time. If you've got something in your head that you want to fix or write, you want to spend time doing just that, not staring at your screen waiting and maybe losing some of your mental model.
If you think a second or two matters when loading an editor you need to cut back on the coffee.
But you normally write code for an hour or many hours. Just opening one or two files for a quick fix sounds more like devops work.
That’s why I never close the project(s) I’m working on. So my startup time is instantaneous
Startup time and crashes seem to be a problem on mine. I compiled my own vscode though so that might have something to do with it.
Still use it exclusively as my C++ IDE with the help of clangd. Would love a native easy to use editor with good support for LSP and vscode's debug protocol. Bonus points if it works in the command line.
Still use it exclusively as my C++ IDE with the help of clangd. Would love a native easy to use editor with good support for LSP and vscode's debug protocol. Bonus points if it works in the command line.
> I'm too much of a skeptic to believe it's just so developers have a warm fuzzy feeling associated with Microsoft...
Given that the development is very-very cheap for Microsoft, even this single thing could make worthwhile for MS to continue the project. VS code appears on HN regularly, it connects to a demographic that's very different from MS's core dev audience.
Given that the development is very-very cheap for Microsoft, even this single thing could make worthwhile for MS to continue the project. VS code appears on HN regularly, it connects to a demographic that's very different from MS's core dev audience.
> guess it requires a degree of sensitivity that I'm not bothered with - sort of like people who claim they can't hear mp3 because they can only enjoy CD quality audio (not saying it's not true for them, just that luckily I enjoy both the same).
Maybe its better on other platforms, but on linux there's 30ms keyboard input latency in vscode, compared to the avg of 6ms I get in sublime.
The perceived difference in responsiveness is significant.
See https://pavelfatin.com/typing-with-pleasure/ if you're curious.
Maybe its better on other platforms, but on linux there's 30ms keyboard input latency in vscode, compared to the avg of 6ms I get in sublime.
The perceived difference in responsiveness is significant.
See https://pavelfatin.com/typing-with-pleasure/ if you're curious.
I just checked on my win7 box. it's about 80ms. Typing in this reply is about 54ms. Notepad was 67ms. All that is like +/- 8ms.
lucky for me it's all unnoticeable.
lucky for me it's all unnoticeable.
My impression is that VSCode is partly about promoting TypeScript, and for what it's worth it has more or less worked on me. Create a "x.ts" and type some stuff; you will see error messages immediately that are roughly as good a first experience with an IDE as I've ever had. I mostly work in Python and Swift, mostly in VSCode, and I wish the support for those languages was nearly so good.
I am an intermediate JS programmer, fiddled with TypeScript a couple of years ago and was unconvinced. Since then TS has matured a lot, and I have been exposed to it in passing from looking at VSCode extensions. If I were to begin a web project today, I would give TypeScript a try. If it weren't for VSCode my thinking would probably be quite different.
As an open source project, VSCode is a significant example of TypeScript on Electron. As a self-hosted IDE I imagine that it has been a good source of feedback for the TypeScript team. I would be very interested to know how many TS issues (checker / compiler bugs, feature requests, etc) have emanated from VSCode.
I am an intermediate JS programmer, fiddled with TypeScript a couple of years ago and was unconvinced. Since then TS has matured a lot, and I have been exposed to it in passing from looking at VSCode extensions. If I were to begin a web project today, I would give TypeScript a try. If it weren't for VSCode my thinking would probably be quite different.
As an open source project, VSCode is a significant example of TypeScript on Electron. As a self-hosted IDE I imagine that it has been a good source of feedback for the TypeScript team. I would be very interested to know how many TS issues (checker / compiler bugs, feature requests, etc) have emanated from VSCode.
> I imagine that it has been a good source of feedback for the TypeScript team. I would be very interested to know how many TS issues (checker / compiler bugs, feature requests, etc) have emanated from VSCode
You can filter by the "VS Code tracked" label on the TypeScript issues which will give you a rough idea.
https://github.com/microsoft/typescript/issues?utf8=%E2%9C%9...
You can filter by the "VS Code tracked" label on the TypeScript issues which will give you a rough idea.
https://github.com/microsoft/typescript/issues?utf8=%E2%9C%9...
Take a look at their telemetry policy, they basically know what type of underpants you are using! Having statistics on what 30% of the worlds' developers are doing and their preferences can be great when making business decisions. It's a bit weird that VScode is intruding on VS market though, it will be interesting when VScode threatens VS - will MS step in and stop them from implementing certain features !?
Minor nitpick, but Chrome has never been Open Source. Sure, it's mostly Chromium, but the point still stands.
True. VSCode is more open source in this sense. Of course, that doesn't mean everyone is happy...
https://github.com/Microsoft/vscode/issues/17996
MS biz is azure-based, so I think the worse can happen is to ship vscode with integrated azure tools...
Makes it really easy to use Azure services.
VS Code is such an excellent open-source project, and also such a great tool despite the obvious and much-bemoaned inherent disadvantages (aka "tradeoffs") that come with being an Electron-based app that it, along with its cousin TypeScript, fundamentally changed my perception of Microsoft.
I'm not monogamous with my code editors and typically have a few of them open.
These days, I notice VSCode is very likely to be one of them.
This roadmap document seems eminently reasonable, and pretty representative of how well-run the VS Code project tends to be.
I'm not monogamous with my code editors and typically have a few of them open.
These days, I notice VSCode is very likely to be one of them.
This roadmap document seems eminently reasonable, and pretty representative of how well-run the VS Code project tends to be.
> I’m not monogamous with my code editors
I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them.
I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode.
I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS/CSS so I use VSCode for all my ‘web’ work.
I’ve also found VSCode to be faster/nicer than IDEA for random things like JSON, SQL, Dockerfiles, Vagrantfiles, Bash scripts.
IDEA generally supports these well enough, but is too noisy (constant bugging about connecting to a data source when opening a SQL file, etc.) or is just lacking a little something compared to VSCode.
I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them.
I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode.
I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS/CSS so I use VSCode for all my ‘web’ work.
I’ve also found VSCode to be faster/nicer than IDEA for random things like JSON, SQL, Dockerfiles, Vagrantfiles, Bash scripts.
IDEA generally supports these well enough, but is too noisy (constant bugging about connecting to a data source when opening a SQL file, etc.) or is just lacking a little something compared to VSCode.
> I’ve always wondered why some people seem so married to a single editor.
Familiarity, such as keyboard shortcuts. Especially for VI(M) or Emacs users, using anything else is an absolute nightmare. If you haven't been spoiled by VIM, then there really isn't much difference between "all those other editors".
:wq
Familiarity, such as keyboard shortcuts. Especially for VI(M) or Emacs users, using anything else is an absolute nightmare. If you haven't been spoiled by VIM, then there really isn't much difference between "all those other editors".
:wq
I started using Emacs like twelve years ago. At this point I'm hopelessly lost to it. My fingers natively speak a language that other editors don't understand.
I use a customized version of the emacs plugin in VSCode and I'm able to use most of the familiar keyboard shortcuts.
> I’ve always wondered why some people seem so married to a single editor.
I'm thinking exactly opposite. I wonder why people change their IDE's/Editors so much between Eclipse/Visual Studio/IntelliJ or between notepad++/sublime-text/atom/VScode/coda/text-mate etc.
What's wrong with using vim or emacs and being happy rest of your career? It's funny so many of my colleagues kid me by saying "emacs is a great operating system but it lacks a good editor" without ever trying it while I'm using emacs without a problem for the last 6-7 years and people around me changing their editors every year to "popular editor of the year" for better features/performance.
I'm thinking exactly opposite. I wonder why people change their IDE's/Editors so much between Eclipse/Visual Studio/IntelliJ or between notepad++/sublime-text/atom/VScode/coda/text-mate etc.
What's wrong with using vim or emacs and being happy rest of your career? It's funny so many of my colleagues kid me by saying "emacs is a great operating system but it lacks a good editor" without ever trying it while I'm using emacs without a problem for the last 6-7 years and people around me changing their editors every year to "popular editor of the year" for better features/performance.
> It's funny so many of my colleagues kid me by saying "emacs is a great operating system but it lacks a good editor" without ever trying it while I'm using emacs without a problem for the last 6-7 years and people around me changing their editors every year
I thought only the vim users used that refrain. vim users are also unlikely to switch to a different editor.
I thought only the vim users used that refrain. vim users are also unlikely to switch to a different editor.
Vim users used to, but now that emacs has a decent text editor[0], they can't.
[0]: https://github.com/emacs-evil/evil
[0]: https://github.com/emacs-evil/evil
or even better - https://github.com/syl20bnr/spacemacs
> What's wrong with using vim or emacs and being happy rest of your career?
I agree with your basic notion -- it takes quite some time to be really fluent with serious IDEs and editors, so changing is inefficient.
But just one editor/IDE doesn't work for everyone. If you favour a GUI-only editor like Sublime Text, for example, then you probably need to also know a console-based one. Or if like me you prefer a heavy IDE for most project work, you probably need to be fluent with a lightweight editor.
For me IntelliJ IDEA + emacs covers all the bases. I'll look briefly at new tools to keep familiar with the landscape, but I'd rather invest the time it would take to learn them into something which will improve my skills in something more useful to the craft than just more tools that do essentially the same things.
I agree with your basic notion -- it takes quite some time to be really fluent with serious IDEs and editors, so changing is inefficient.
But just one editor/IDE doesn't work for everyone. If you favour a GUI-only editor like Sublime Text, for example, then you probably need to also know a console-based one. Or if like me you prefer a heavy IDE for most project work, you probably need to be fluent with a lightweight editor.
For me IntelliJ IDEA + emacs covers all the bases. I'll look briefly at new tools to keep familiar with the landscape, but I'd rather invest the time it would take to learn them into something which will improve my skills in something more useful to the craft than just more tools that do essentially the same things.
I used EditPlus for over 8 years until SublimeText appeared, and have been using it for the last five years.
I think your point applies to current users of Atom/VSCode, but for me Sublime has stood the test of time, again and again.
I think your point applies to current users of Atom/VSCode, but for me Sublime has stood the test of time, again and again.
I’m not married to an editor so much as my bindings. I’d really hate to use an editor/ide that doesn’t have a decent implementation of at least some vim bindings, though I have to sometimes.
Ultimately I think it’s familiarity and a subtle fear that learning any new system will be a time sink.
Ultimately I think it’s familiarity and a subtle fear that learning any new system will be a time sink.
> I’m not married to an editor so much as my bindings.
Agreed, and it's extremely annoying that VS Code has different default bindings on different platforms. I switch between Windows and Linux a lot and there's no simple way to e.g. say "use the default Windows bindings on Linux" or vice-versa.
I have to manually create my own keybindings and then copy them to every machine and then bother with keeping them in sync.
Agreed, and it's extremely annoying that VS Code has different default bindings on different platforms. I switch between Windows and Linux a lot and there's no simple way to e.g. say "use the default Windows bindings on Linux" or vice-versa.
I have to manually create my own keybindings and then copy them to every machine and then bother with keeping them in sync.
I'm using the IntelliJ bindings plugin together with the VIM bindings and get almost constantly the same bindings on all platforms that way...
I'm not sure. I heavily switch between VIM and VSCode. I sometimes dive back into Emacs. It really depends on what I'm doing. But I like the refreshing feeling of using a different editor.
Re. a single editor: The constant, never-ending search for The Perfect Editor :)
> VS Code .. fundamentally changed my perception of Microsoft.
It certainly changed my perception of electron. I don't use it daily because my editing requirements are already well met, but it really is a lovely piece of work.
It certainly changed my perception of electron. I don't use it daily because my editing requirements are already well met, but it really is a lovely piece of work.
As much as I wanted to like and use VS Code, Electron base still ruined it for me. If it was some other app where I do not expect instant snappiness and lower memory usage, for example, Slack (also Electron app), I would swallow it, but for an editor, I can`t.
I upvoted you to try to offset the misguided downvotes. That is indeed the worst thing about VS Code.
I have my computer configured so that most file types open in Sublime Text for that reason. For projects with a lot of TypeScript I'll open a project folder in VSCode, and then just leave it open indefinitely. Because that part is annoyingly slow, as you say.
I find it less annoying than Slack, though — seems to me that once VSCode is open and focused on what you want, it is a lot faster than Slack at all the basic operations (switching files/channels, searching, etc). Slack feels more like most other Electron apps I have tried — slow enough at just about every little thing to be constantly annoying.
I have my computer configured so that most file types open in Sublime Text for that reason. For projects with a lot of TypeScript I'll open a project folder in VSCode, and then just leave it open indefinitely. Because that part is annoyingly slow, as you say.
I find it less annoying than Slack, though — seems to me that once VSCode is open and focused on what you want, it is a lot faster than Slack at all the basic operations (switching files/channels, searching, etc). Slack feels more like most other Electron apps I have tried — slow enough at just about every little thing to be constantly annoying.
Why do people use desktop Slack? I always run it my browser, I just don't see the value proposition of a native application?
Don't it get lost or closed by mistake all the time?
To me much of the value of a separate app is being able to cmd+tab between application and I frequently just close my browser be get remove all windows and tabs.
I like the compartmentalisation of separate apps, but I doesn't really care if it's written as an Electron app, as long as reacts fast enough.
I like the compartmentalisation of separate apps, but I doesn't really care if it's written as an Electron app, as long as reacts fast enough.
Not OP, but my browser is open pretty much all the time, and pinning tabs ensures they don't get lost.
So today I just learned you can pin tabs :)
Next lesson: you can switch to the n'th tab using Alt+<n> (or perhaps a different modifier key depending on browser and OS). Since pinned tabs appear on the left-hand side, that means you'll always have e.g. Alt+1 for email, Alt+2 for calendar, etc.
(Nice and related is that you can do Super+<n> for window switching in at least Windows and Ubuntu.)
(Nice and related is that you can do Super+<n> for window switching in at least Windows and Ubuntu.)
I have GitHub, slack, Gmail, calendar and JIRA always pinned. That’s my most used web apps.
Can’t imagine them each having a desktop app. I would just get lost switching tabs.
Can’t imagine them each having a desktop app. I would just get lost switching tabs.
Pinned tabs still get closed with Ctrl/Cmd+Shift+W, which is a bit of a drag.
I make SSB apps for my most used websites, for me it's much faster than:
- switch to chrome
- switch to chrome window with pinned tab
- switch to pinned tab
I make SSB apps for my most used websites, for me it's much faster than:
- switch to chrome
- switch to chrome window with pinned tab
- switch to pinned tab
I just use the --app flag for Chrome. Basically gets me an SSB, but still lets me right-click to open links in different profiles.
SSB?
"Single-site browser", or "site specific browser".
Basically a very thin wrapper over the systems web view.
Basically a very thin wrapper over the systems web view.
Me, too. For instance, I use a site-specific browser for:
- CircleCI
- GitHub
- JIRA (blecch, but I have to use it...)
- AWS
- Google Docs (for work, and the rare personal use of Google stuff can just happen in one of the general browsers I am using)
...and others.
The OS does a much better job of partitioning windows and groups of windows than a browser typically does. You can easily keep switch between groups of windows, or keep them in their own workspace/desktop, etc.
Plus you can keep your cookies and saved passwords isolated between the environments... the browser handling AWS doesn't need to store or have access to the pasword for my Google account, and so on. For production type apps you can disable saved passwords entirely.
It is incredibly useful, and the only thing I worry about is that on macOS (my main workstation OS) there is only one good solution for this I know of: Epichrome, which seems to be a one-man side project:
https://github.com/dmarmor/epichrome
Other solutions that I know of don't save passwords, or don't keep password/cookie stores separated between the browser instances.
(I think Chrome can do this by itself on other platforms.)
- CircleCI
- GitHub
- JIRA (blecch, but I have to use it...)
- AWS
- Google Docs (for work, and the rare personal use of Google stuff can just happen in one of the general browsers I am using)
...and others.
The OS does a much better job of partitioning windows and groups of windows than a browser typically does. You can easily keep switch between groups of windows, or keep them in their own workspace/desktop, etc.
Plus you can keep your cookies and saved passwords isolated between the environments... the browser handling AWS doesn't need to store or have access to the pasword for my Google account, and so on. For production type apps you can disable saved passwords entirely.
It is incredibly useful, and the only thing I worry about is that on macOS (my main workstation OS) there is only one good solution for this I know of: Epichrome, which seems to be a one-man side project:
https://github.com/dmarmor/epichrome
Other solutions that I know of don't save passwords, or don't keep password/cookie stores separated between the browser instances.
(I think Chrome can do this by itself on other platforms.)
See MacPin (https://github.com/kfix/MacPin/tree/swift2.3) and FluidApp (http://fluidapp.com/).
And yes, Chrome, at least on windows, has an `--app` switch.
And yes, Chrome, at least on windows, has an `--app` switch.
The Chrome --app switch doesn't work on Mac.
FluidApp can't save passwords.
MacPin looks interesting! Thanks, will check it out. However, Safari-based browsers have a horrible show-stopping flaw; they don't (yet) support pasting images into web applications. This is why I love Safari for browsing and reading, but can't bear to use it for JIRA, GitHub, etc.
In Chrome (and thus Epichrome), you just hit your screen capture shortcut (Cmd-Shift-Ctrl-4 by default on macOS), select a rect of the screen to copy, and paste. Boom! Your bug report or GitHub comment now has an image pasted into it.
In Safari, you have to hit your screen capture shortcut, open Preview or similar app, create a new image, save it as a file, then go back to the web app and upload the image.
There's something deeply, horrifically wrong with that workflow.
FluidApp can't save passwords.
MacPin looks interesting! Thanks, will check it out. However, Safari-based browsers have a horrible show-stopping flaw; they don't (yet) support pasting images into web applications. This is why I love Safari for browsing and reading, but can't bear to use it for JIRA, GitHub, etc.
In Chrome (and thus Epichrome), you just hit your screen capture shortcut (Cmd-Shift-Ctrl-4 by default on macOS), select a rect of the screen to copy, and paste. Boom! Your bug report or GitHub comment now has an image pasted into it.
In Safari, you have to hit your screen capture shortcut, open Preview or similar app, create a new image, save it as a file, then go back to the web app and upload the image.
There's something deeply, horrifically wrong with that workflow.
Uh, I believe Cmd-Shift-4 saves the image directly to the desktop, then I usually hit one of my hot corners that shows the desktop, grab it, hit the corner again and drop in the image. It's usually pretty quick. I did not know about holding Ctrl copies the file, I'll probably use that more often now because it probably is a little faster. But if you want to save an image you don't have to open up preview to save it or anything.
For me it's just saving me from minor inconveniences. Things like having an app I can easily switch to instead of flicking through many browser windows/tabs to dig it out.
I try to offload as much stuff from the web and into the desktop because it means I can do all my window management with cmd+tab and Spectacle. If something lives in the browser I have a second layer to manage with ctrl+tab, slowing me and increasing mental load.
My full setup is cmd+tab for application switching, Spectacle for window ordering, and ctrl+arrows for switching Spaces. Space 1 is my 'grab-bag' desktop, Space 2 is my browser windows, Space 3 is all my code editing stuff, Space 4 is messaging (Telegram/IRC/Slack) Space 5 is Spotify and Space 6 is Mail and Calendar. All applications are 'pinned' to only open in their respective Space, but can be dragged to another one manually. I like to think of it as a best-of-both worlds hybrid between stacking window management and tiling window management :)
My full setup is cmd+tab for application switching, Spectacle for window ordering, and ctrl+arrows for switching Spaces. Space 1 is my 'grab-bag' desktop, Space 2 is my browser windows, Space 3 is all my code editing stuff, Space 4 is messaging (Telegram/IRC/Slack) Space 5 is Spotify and Space 6 is Mail and Calendar. All applications are 'pinned' to only open in their respective Space, but can be dragged to another one manually. I like to think of it as a best-of-both worlds hybrid between stacking window management and tiling window management :)
To me a native application just feels more... native. If everything is in the browser then the OS just becomes a secondary thing.
> native application
Since when is Electron running a web view a native application?
Since when is Electron running a web view a native application?
I can see that if you close your editor often. I don't.
By the way checkout GitLens on VS Code.
By the way checkout GitLens on VS Code.
Well, the regular Visual Studio is a native app and has terrible performance and memory usage too.
(joking but also serious)
(joking but also serious)
The regular Visual Studio uses about the same amount of memory as VSCode while being an order of magnitude more complex and feature-rich.
A small bit of anecdotal evidence:
We have a solution with around 30 projects in it - this solution consumes around 1.25gb of RAM in Visual Studio. In contrast, the same solution in VS Code open along with two other windows open to other solutions are using a total less than around 300mb.
We have a solution with around 30 projects in it - this solution consumes around 1.25gb of RAM in Visual Studio. In contrast, the same solution in VS Code open along with two other windows open to other solutions are using a total less than around 300mb.
I use VSCode to work on medium-sized VueJS+TypeScript projects (maybe a grand total of 200 code files), and it regularly consumes around 800mb - VS territory. Perhaps it's very sensitive to how it's configured/what plugins are installed.
Do you use ReSharper? Keep in mind that it adds a good chunk of overhead.
Yet I have 32 GB of RAM on my machine, and rather than use any of that, VS2017 will just use < 2GB, and swap constantly on large solutions. The 32-bit restriction is getting ridiculous.
Its the main reason I'm excited about Rider.
Its the main reason I'm excited about Rider.
I assume you use ReSharper? I have a 1M+ LOC C++ application that I work on regularly and have never had a performance issue. There was definitely slow down when I moved from VC6 to VS2005, but man, that was so long ago.
> Electron base still ruined it for me
It works just fine for me. It's just as usable as any other editor. It slightly less snappy that vim in a terminal, but it doesn't make much of a difference most of the time. I still use vim occasionally though in some contexts (single file editing, constraint environment...).
It works just fine for me. It's just as usable as any other editor. It slightly less snappy that vim in a terminal, but it doesn't make much of a difference most of the time. I still use vim occasionally though in some contexts (single file editing, constraint environment...).
I think there are a lot of people who open and close their editors pretty regularly, I can imagine that the start-up time for VSCode can become quite significant to those people.
I don’t think Electron is entirely to blame e.g. I tried the Discord app and it was amazingly snappy (just install both Slack and Discord and you can feel the difference).
Just compare VSCode with Atom - both Electron apps, both text editors, both extensible in JS.
I can't realistically measure input lag and stuff, but for example... With both having lots of extensions doing approximately the same, startup time is order of magnitude different. (And once upon a time I thought Emacs was bad in this regard, huh)
I can't realistically measure input lag and stuff, but for example... With both having lots of extensions doing approximately the same, startup time is order of magnitude different. (And once upon a time I thought Emacs was bad in this regard, huh)
I actually really want to know how Discord does it. Do they actually use the DOM, or just draw everything themselves?
Honestly, anyone who hasn't used Discord, I'd recommend installing it just to try it, especially if you're a SPA web developer or you work with Electron. The performance beats native apps, even dealing with very long sections of text that need to be swapped in and out as you scroll.
However they're doing it is probably the way we should be building Electron applications industry-wide.
Honestly, anyone who hasn't used Discord, I'd recommend installing it just to try it, especially if you're a SPA web developer or you work with Electron. The performance beats native apps, even dealing with very long sections of text that need to be swapped in and out as you scroll.
However they're doing it is probably the way we should be building Electron applications industry-wide.
> I actually really want to know how Discord does it.
I tried asking them on Twitter and the reply was ‘magic’.
I tried asking them on Twitter and the reply was ‘magic’.
> Do they actually use the DOM, or just draw everything themselves?
The DOM is fast — what's slow are toolkits or poorly structured code which issues many redundant or poorly timed updates which forces the browser engine to do unnecessary updates.
The DOM is fast — what's slow are toolkits or poorly structured code which issues many redundant or poorly timed updates which forces the browser engine to do unnecessary updates.
How much memory does it use? My emacs instance uses ~200M with a moderate amount of files(along with other processes mostly repls). I would imagine VSCode to be in the same ballpark, and 200M is not that of a big deal imo.
Here is a hint of performance
https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
But an even better test is when using these editors on large projects with hundreds or thousands of files. Atom is a disaster. I tried to like VSCode and except Electron part and baggage it is great.
For this reason, I am switching to vim for everything except Java/Kotlin. There is nothing even remotely close to IntelliJ for Java or Kotlin and you can use very nice vim bindings in IntelliJ. I also keep Sublime installed for quick file edits when browsing the filesystem with GUI apps.
https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
But an even better test is when using these editors on large projects with hundreds or thousands of files. Atom is a disaster. I tried to like VSCode and except Electron part and baggage it is great.
For this reason, I am switching to vim for everything except Java/Kotlin. There is nothing even remotely close to IntelliJ for Java or Kotlin and you can use very nice vim bindings in IntelliJ. I also keep Sublime installed for quick file edits when browsing the filesystem with GUI apps.
The IdeaVIM plugin for IntelliJ is excellent, I use it in PHPStorm and PyCharm.
https://github.com/JetBrains/ideavim
https://github.com/JetBrains/ideavim
177 MB for me, right now. However that's just the windows task manager, so it's properly not accurate.
> 177 MB for me, right now. However that's just the windows task manager, so it's properly not accurate.
I don't see why it shouldn't be. Just make sure you're reading the right column. In this case I think you want to look at "Commit Size".
I don't see why it shouldn't be. Just make sure you're reading the right column. In this case I think you want to look at "Commit Size".
Task manager shows working set by default. Working set is affected by things like minimizing the application, it'll also usually shrink if the application has been left idle for some time and other applications are being used. Whether it's the right column or not depends; it's more of an indication of how much the OS feels that it needs to hand over to the process, than how memory-hungry the process is. Private bytes might be a better number for that; OTOH if many of the bytes aren't touched, then they don't count for much.
I wrote up an explanation for some of the other columns a few years back: https://stackoverflow.com/a/2031886/3712
I wrote up an explanation for some of the other columns a few years back: https://stackoverflow.com/a/2031886/3712
That's why I explicitly said you have to look at the correct column though: you need to look at Commit Size, not Working Set.
Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file.
Here's another article with more recent details: http://blogs.microsoft.co.il/sasha/2016/01/05/windows-proces...
Here's another article with more recent details: http://blogs.microsoft.co.il/sasha/2016/01/05/windows-proces...
> Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file.
No.
Short response: Try committing 1 TiB of memory without touching it and tell me how successful you are.
Long response: Unlike Linux, Windows doesn't overcommit. It is completely irrelevant whether physical pages have been actually allocated to back the the virtual pages that are committed. The fact that the virtual pages are committed means that there are guaranteed to be physical pages available somewhere when the need arises for them to be allocated (whether they are in the page file or in physical memory is irrelevant; what matters is that the storage space exists one-to-one), i.e. the fact that some virtual pages are committed means you have lost that much physical memory from the system already... which is exactly the number you want to look at when you're trying to figure out how much memory a program is using (since the entire point is to see how much memory it'll leave you for other programs).
(And shared memory is pretty much irrelevant for VSCode so let's not go on an irrelevant tangent.)
No.
Short response: Try committing 1 TiB of memory without touching it and tell me how successful you are.
Long response: Unlike Linux, Windows doesn't overcommit. It is completely irrelevant whether physical pages have been actually allocated to back the the virtual pages that are committed. The fact that the virtual pages are committed means that there are guaranteed to be physical pages available somewhere when the need arises for them to be allocated (whether they are in the page file or in physical memory is irrelevant; what matters is that the storage space exists one-to-one), i.e. the fact that some virtual pages are committed means you have lost that much physical memory from the system already... which is exactly the number you want to look at when you're trying to figure out how much memory a program is using (since the entire point is to see how much memory it'll leave you for other programs).
(And shared memory is pretty much irrelevant for VSCode so let's not go on an irrelevant tangent.)
> It is completely irrelevant whether physical pages have been actually allocated to back the the virtual pages that are committed
It is in fact the only relevant thing with memory; physical memory is the constrained resource. If you're constrained on swap space, you're going to spend the rest of the year swapping.
Overcommitting is neither here nor there; a failure to have a backing store for memory (whether in physical memory or page file) will result in OOM, but nobody is actually worried about OOM. Editors and systems lose responsiveness long before then. The failure mode from apps using too much memory is swapping, not OOM.
Part of the reason measuring memory usage from a process stats perspective is so hard is because some memory is more important than others; in particular, access patterns matter. If a process is starting to swap, whether you see a cliff edge in performance, or a more gradual decline, comes down to the access pattern. The working set concept approximates the "frequently used" quantity of memory, which is why Task Manager uses it by default, but it's subtle since it's not a simple function of allocation.
It is in fact the only relevant thing with memory; physical memory is the constrained resource. If you're constrained on swap space, you're going to spend the rest of the year swapping.
Overcommitting is neither here nor there; a failure to have a backing store for memory (whether in physical memory or page file) will result in OOM, but nobody is actually worried about OOM. Editors and systems lose responsiveness long before then. The failure mode from apps using too much memory is swapping, not OOM.
Part of the reason measuring memory usage from a process stats perspective is so hard is because some memory is more important than others; in particular, access patterns matter. If a process is starting to swap, whether you see a cliff edge in performance, or a more gradual decline, comes down to the access pattern. The working set concept approximates the "frequently used" quantity of memory, which is why Task Manager uses it by default, but it's subtle since it's not a simple function of allocation.
[deleted]
I'm a little bit philosophically opposed to Electron based apps but VSCode has been nothing but snappy for me on all matter of low-end machines and virtual machines I've used it on.
Quoting myself:
>If there were no other way to code a text editor I could accept the idea of Atom. But with faster alternatives, it is just an exercise in consumerism. Wasting computing power for the sake of wasting computing power.
>It's the rolling coal of computers.
>If there were no other way to code a text editor I could accept the idea of Atom. But with faster alternatives, it is just an exercise in consumerism. Wasting computing power for the sake of wasting computing power.
>It's the rolling coal of computers.
Why is Slack being an Electron-based app more tolerable? I find it absurd that you need a whole browser to make a chat app.
More tolerable in a scence that I could live with 1-3s occasional actions in it (switching organisations for example). Not saying that it is good. But I will tolerate that more than the editor hanging on large files or taking to long to process actions which should be instantanious.
My main wish for VS Code is 'proper' multiple cursors (where by 'proper' I mean 'works the way I expect' which is the Sublime Text way).
I fully understand that if you come from a world of 2D blocks (or regions) where you can select rectangles then VS Code's way of doing things makes sense but I am so used to having multiple identical cursors and being able to swipe vertical lines through tables of text or more often down the ragged right hand side that I find VS Code frustrating for hard-core text editing.
I seem to start every new project using it and I love its language-specific coding tools (and how it handles extensions) but as soon as I need to do a large edit on a nasty piece of text I find myself switching back to Sublime.
(I will of course give it another go as soon as I start another new project)
I fully understand that if you come from a world of 2D blocks (or regions) where you can select rectangles then VS Code's way of doing things makes sense but I am so used to having multiple identical cursors and being able to swipe vertical lines through tables of text or more often down the ragged right hand side that I find VS Code frustrating for hard-core text editing.
I seem to start every new project using it and I love its language-specific coding tools (and how it handles extensions) but as soon as I need to do a large edit on a nasty piece of text I find myself switching back to Sublime.
(I will of course give it another go as soon as I start another new project)
shift+alt click seems to behave just like sublime does, I left sublime a long time ago, I'm not sure what you're trying to describe there?
Do you mean because it selects the rectangle? Just hit an arrow key.
Do you mean because it selects the rectangle? Just hit an arrow key.
Last I tried you couldn't scrape down the right side of the ragged edge. I'll try it out again as maybe it's fixed.
I also found the 'extra' cursors too faint previously. Hopefully that's been improved too.
I'll give it a go as there's so much to like about it.
I also found the 'extra' cursors too faint previously. Hopefully that's been improved too.
I'll give it a go as there's so much to like about it.
Ah I see what you mean.
I wouldn't call that a problem per-se. It draws a cursor where there it text to draw one. This makes sense to me as I can edit a column of values and not pick up already empty columns.
To do what you want I'd just multi-cursor the start of all the lines and hit end. Usually ctrl+arrow over word boundaries gets anywhere I need after that.
Anything fancier still I've just written a regex instead.
Could certainly be a preference option to enable blank lines on multiple cursors. it would have to fill the white space.
I wouldn't call that a problem per-se. It draws a cursor where there it text to draw one. This makes sense to me as I can edit a column of values and not pick up already empty columns.
To do what you want I'd just multi-cursor the start of all the lines and hit end. Usually ctrl+arrow over word boundaries gets anywhere I need after that.
Anything fancier still I've just written a regex instead.
Could certainly be a preference option to enable blank lines on multiple cursors. it would have to fill the white space.
I've tried it and there is still a problem: the cursors draw from wherever the previous cursor was. This makes it impossible to draw a line of cursors vertically through your text without first placing a single cursor at either the top of the bottom of where you want to draw the line. So instead of click-drag (with a modifier key) you have to click-click-drag (with a modifier key).
I do find the click-click drag annoying too.
I've also tried to put cursors along a ragged right edge and that doesn't work as it tries to create a rectangular selection. It looks like its worked but as soon as you hit a cursor key the cursors try to line up and you end up with cursors at odd positions. Very odd.
Right- or ‘end’ to get cursors onto the end of every line
Hi, I'm a VS Code developer.
Can you please open a new issue and describe "as you would to a five year old" what's not working as expected.
Even from reading this comment thread I simply don't get it, so it might be something very easy to fix, once I do understand what it's about.
Thank you for your patience! :)
Can you please open a new issue and describe "as you would to a five year old" what's not working as expected.
Even from reading this comment thread I simply don't get it, so it might be something very easy to fix, once I do understand what it's about.
Thank you for your patience! :)
Whoop! Would love to—thanks for your time :)
I haven't used Sublime in years now, but that was one huge feature I think about and miss often when in VSCode. I'm glad VSCode does have the current implementation of multiple cursors, and the way Sublime did it differently is subtle, but man it makes a huge difference!
I'd love to have an editor scripting language in VS Code that would be a lighter-weight way to create an editing macro than building an extension. Despite the annoying scripting languages, both vim and emacs get a lot of their power and popularity by enabling users to easily add little, custom editing features that they can then bind to keystrokes.
Not a macro recorder, but a real scripting language in which cursors, multiple selections, find results, regexes, files, folders, editor panels, the built-in terminal, menu items, semantics provided by an extension (ex: "PythonFunctionName"), external processes, git merge conflict lines, etc., were first-class objects.
Now there's a stretch goal....
Not a macro recorder, but a real scripting language in which cursors, multiple selections, find results, regexes, files, folders, editor panels, the built-in terminal, menu items, semantics provided by an extension (ex: "PythonFunctionName"), external processes, git merge conflict lines, etc., were first-class objects.
Now there's a stretch goal....
The scripting language would most likely be JavaScript, of course.
I don't use VS Code and I'm surprised there isn't already a lightweight way to run some JavaScript code to script the editor. Are you saying you need to bundle up any code you write in a proper extension before you are allowed to run it? Sounds bureaucratic to me, VS Code should learn from Emacs.
I don't use VS Code and I'm surprised there isn't already a lightweight way to run some JavaScript code to script the editor. Are you saying you need to bundle up any code you write in a proper extension before you are allowed to run it? Sounds bureaucratic to me, VS Code should learn from Emacs.
[deleted]
Given that it's an Electron app, wouldn't it suffice to use plain JavaScript (or TypeScript, given that part of the editor's raison d'être), and add a few extra "built-in" modules specific to the VS Code environment?
Yes, I think that would be just fine as long as the modules encapsulated the "native" functionality of the editor. As long as developers could easily orchestrate and build on top of existing editor (& built-in git, terminal, extension, etc.) functionality without having to reimplement it from basic JS string processing, JS (incl. but not requiring TS) would seem the logical choice.
I tried VS Code for a few weeks and really liked it. In particular, it's super super fast (compared to vim, spacemacs, emacs and atom, all of which I've used in recent history). It's by far the fastest and smoothest text editor I've used and I was sad to leave it.
I left it because the Vim mode is completely unusable. None of the commands work like you expect them to, undo was broken and I'd periodically lose my undo history. Everything was just a little bit wrong. Which is a shame because it's otherwise a really fantastic editor.
I left it because the Vim mode is completely unusable. None of the commands work like you expect them to, undo was broken and I'd periodically lose my undo history. Everything was just a little bit wrong. Which is a shame because it's otherwise a really fantastic editor.
You found it to be fast in comparison to vim and emacs? I am surprised to hear someone say this. I also think it is plenty fast for my needs, but certainly not faster than vim or emacs.
Did you mean fast in terms of performance, or in terms of your ability to edit, or something else? And you weren't using a GUI version of vim/emacs, right?
Did you mean fast in terms of performance, or in terms of your ability to edit, or something else? And you weren't using a GUI version of vim/emacs, right?
Yes, absolutely. I'm running vim in iterm2, and I haven't had time to figure out why it's slow. Things that are really slow in vim are scroll speed, a 1s-ish pause when ALE fills the quickfix window, and an undiagnosed merlin-related pause when opening ocaml files.
So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (not that it's really that fast otherwise).
By contrast, no plugin I loaded made VS Code slow, and it was super smooth and fast to do, yes, scrolling, all the time.
My current emacs is via spacemacs, and I'm only using it for magit. Apart from asking me to update .recentf EVERY SINGLE TIME I refresh magit, it also takes a very noticeable pause to update the git status. By contrast, that was completely backgrounded in VS Code (though I didn't really use it since I prefer magit, so apples and oranges comparison here).
TL;DR: vim is not fast, especially not if you want to do something like use it in a terminal with plugins. VS Code is actually really fast.
So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (not that it's really that fast otherwise).
By contrast, no plugin I loaded made VS Code slow, and it was super smooth and fast to do, yes, scrolling, all the time.
My current emacs is via spacemacs, and I'm only using it for magit. Apart from asking me to update .recentf EVERY SINGLE TIME I refresh magit, it also takes a very noticeable pause to update the git status. By contrast, that was completely backgrounded in VS Code (though I didn't really use it since I prefer magit, so apples and oranges comparison here).
TL;DR: vim is not fast, especially not if you want to do something like use it in a terminal with plugins. VS Code is actually really fast.
I definitely share the sentiment that Spacemacs is slow, which annoys the crap out of me (for a lot of things it feels less performant than Atom/VSCode because people don’t write things in an async way in elisp often it seems).
With regards to vim though, there is no reason for it to be slow, except for some specific plugin pulling you down. Are you using synchronous linters? I thought Ale was async. I would also recommend vim-plug and lazy loading for plugin management.
I’m on Mac myself and use vim regularly in iTerm, Terminal.app and Gui, and am currently not experiencing any problems. Of course, environments vary.
Also, you can try switching out your vim with neovim, which should work seamlessly.
With regards to vim though, there is no reason for it to be slow, except for some specific plugin pulling you down. Are you using synchronous linters? I thought Ale was async. I would also recommend vim-plug and lazy loading for plugin management.
I’m on Mac myself and use vim regularly in iTerm, Terminal.app and Gui, and am currently not experiencing any problems. Of course, environments vary.
Also, you can try switching out your vim with neovim, which should work seamlessly.
It's not just plugins slow Vim down, a few things that come with Vim are slow too.
The worst is probably language specific support for LaTeX files, particularly syntax highlighting, there is even a tex-slow (http://vimdoc.sourceforge.net/htmldoc/syntax.html#tex-slow) entry in the Vim manual. On my old netbook (haven't heard that word in years!) it was so bad Vim lagged behind my typing, and I'm not particularly fast. I turned off syntax highlighting which fixed the lag, but missed it so much I switched to Emacs instead (and discovered AucTeX which is fantastic, so I wouldn't switch back now).
The worst is probably language specific support for LaTeX files, particularly syntax highlighting, there is even a tex-slow (http://vimdoc.sourceforge.net/htmldoc/syntax.html#tex-slow) entry in the Vim manual. On my old netbook (haven't heard that word in years!) it was so bad Vim lagged behind my typing, and I'm not particularly fast. I turned off syntax highlighting which fixed the lag, but missed it so much I switched to Emacs instead (and discovered AucTeX which is fantastic, so I wouldn't switch back now).
iterm has terrible latency, you should try using alacritty - way faster.
Unfortunatley Alacritty has the same issues:
From Alacritty's FAQ: Q: "macOS + tmux + vim is slow! I thought this was supposed to be fast! This appears to be an issue outside of terminal emulators; either macOS has an IPC performance issue, or either tmux or vim (or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app. I've found that if tmux is running on another machine which is connected to Alacritty via SSH, this issue disappears. Actual throughput and rendering performance are still better in Alacritty."
From Alacritty's FAQ: Q: "macOS + tmux + vim is slow! I thought this was supposed to be fast! This appears to be an issue outside of terminal emulators; either macOS has an IPC performance issue, or either tmux or vim (or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app. I've found that if tmux is running on another machine which is connected to Alacritty via SSH, this issue disappears. Actual throughput and rendering performance are still better in Alacritty."
I did, but it didn't work all that well for me. I just tried it a minute ago. However, I found that macvim was way better for me, once I figured out how to make it look as pretty.
Vim can be really slow with too many plugins running.
I've also noticed that it's slow on Macs for some reason too. The same set of plugins don't seem to cause a slowdown on Linux.
That's very strange, it seems to be the case for both Vim and Neovim, and it doesn't depend on the terminal or shell I'm using. Is it just something inherent in the Mac environment then? I was always left scratching my head over the number of plug-ins people used, wondering how the program was even functional for them.
I don't really know, as I haven't looked into it much. But my vim config is in git and shared between Linux and Mac laptops. On Linux (2013 Thinkpad) I can't really detect much lag at all, but on the Mac (2015 MBPro) it's really quite annoying - to the point it subjectively seems about as "slow" as Atom. Interactive things like scrolling are especially annoying - non interactive things seem ok though.
I'm no Vim or Mac OS poweruser though - I've just kinda put up with or avoided it. Sorry I couldn't really offer much beyond confirmation :)
I'm no Vim or Mac OS poweruser though - I've just kinda put up with or avoided it. Sorry I couldn't really offer much beyond confirmation :)
Thank you! I have a HUGE bias against Apple in general but when I am using a Mac I have always find it laggy compared to my Linux and even Windows terminals.
There is parallelism in new vim now
The vim emulation plugin has gotten better recently, IMO it's the best I've seen in a GUI editor. The undo history thing sort of persists because the vim plugin maintains a different undo history than vscode. They implement undo branches whereas VSCode's native undo stack does not, and the native stack only sees large chunks of changes instead of individual actions.
I'm actually working on a fork of VSCode that rewrites their native undo stack to support branching and more granular control so the vim plugin can sync to it and not maintain two undo histories. We're hoping to submit a PR for that soonish, as soon as school stops kicking my butt.
I'm actually working on a fork of VSCode that rewrites their native undo stack to support branching and more granular control so the vim plugin can sync to it and not maintain two undo histories. We're hoping to submit a PR for that soonish, as soon as school stops kicking my butt.
I'm not sure about the boundary where "editor" ends and "IDE" begins, and I'm not sure which side VS Code falls on at this point.
Either way, I think it worth mentioning that the Vim emulation plugin for JetBrains' products is truly the best out there... and a great milestone for others to strive toward. The scope of what's emulated (including Vim-style search and replace), the ability to cherry pick which keyboard shortcuts use Vim mappings and which use the native editor mappings, etc.
In my humble opinion, IntelliJ is a better Vim than Vim is. I noodle around with VS Code here and there... but it's approaching an uncanny valley point where it's too heavy for use as a plain text editor, but not able to compete with WebStorm (or whatever) as a web IDE.
Either way, I think it worth mentioning that the Vim emulation plugin for JetBrains' products is truly the best out there... and a great milestone for others to strive toward. The scope of what's emulated (including Vim-style search and replace), the ability to cherry pick which keyboard shortcuts use Vim mappings and which use the native editor mappings, etc.
In my humble opinion, IntelliJ is a better Vim than Vim is. I noodle around with VS Code here and there... but it's approaching an uncanny valley point where it's too heavy for use as a plain text editor, but not able to compete with WebStorm (or whatever) as a web IDE.
It is surely faster than Atom, but not on the same league as sublime, emacs or vim.
Emacs modes normally use regular expressions for everything from syntax highlighting to semantic insights. This does not make it fast. Emacs performance usually degrades linearly with the size of the file being edited, and most CPU activity occurs synchronously and blocks the UI.
I don't think Emacs is a fast editor unless you run it bare with -Q, at which point you've left out all the stuff that makes Emacs useful.
IMO it ought to provide a state machine engine for modes to use to do syntax highlighting, something that it can cache at line boundaries, stop and start electively depending on bit of the buffer is displayed in the current window, evaluate the state machine on a background thread (so, concurrent with actual usage, unlike the idle work it already does), etc. A state machine without extra knobs would only provide lexical highlighting, but I think extra knobs (e.g. variables, stacks) could be added to make it more useful.
The retained mode text styling with font locking etc. is not the optimal design choice for performance, I suspect.
I don't think Emacs is a fast editor unless you run it bare with -Q, at which point you've left out all the stuff that makes Emacs useful.
IMO it ought to provide a state machine engine for modes to use to do syntax highlighting, something that it can cache at line boundaries, stop and start electively depending on bit of the buffer is displayed in the current window, evaluate the state machine on a background thread (so, concurrent with actual usage, unlike the idle work it already does), etc. A state machine without extra knobs would only provide lexical highlighting, but I think extra knobs (e.g. variables, stacks) could be added to make it more useful.
The retained mode text styling with font locking etc. is not the optimal design choice for performance, I suspect.
Emacs, at least in windows, can be surprisingly slow. I think they have fixed some issues with long lines, but those used to be aweful. Also large files can be slow. Also, too many packages is a problem, which we might well see in the future for VS code, too, but the javascript runtime is likely orders of magnitude faster than the emacs one, no?
vim, on the other hand, is supposed to be really quick as far as I have heard!
vim, on the other hand, is supposed to be really quick as far as I have heard!
I only use Emacs on UNIX systems and it is quite fast.
On the old days I was usign XEmacs, which did not had any issue with Windows.
Now if someone is running Emacs as cygwin application, then it might be slow I guess, given that everything on cygwin is slower than pure Win32 applications.
On the old days I was usign XEmacs, which did not had any issue with Windows.
Now if someone is running Emacs as cygwin application, then it might be slow I guess, given that everything on cygwin is slower than pure Win32 applications.
I find VS Code VIM to be the best outside of well VIM and getting better.
I am thinking that in the near future the brain bending of Neovim inside of the a text editor VS Code ecosystem will happen. They already are putting parts of Neovim inside of VS Code editor in the last patch.
I am thinking that in the near future the brain bending of Neovim inside of the a text editor VS Code ecosystem will happen. They already are putting parts of Neovim inside of VS Code editor in the last patch.
I just can’t put my finger on it, but in VSCode I very frequently end up in a weird vim state where I just have to hit escape until it resets to normal mode. There just seems to be a lot of corner cases or something that I end up hitting frequently.
And I’m fairly certain that is not on my part seeing as both vim itself, Spacemacs and Atom’s vim mode work superbly for me. It’s one of those things where VSCode just ends up irking me too much and I switch back to other editors :/
And I’m fairly certain that is not on my part seeing as both vim itself, Spacemacs and Atom’s vim mode work superbly for me. It’s one of those things where VSCode just ends up irking me too much and I switch back to other editors :/
I suspect what you're running into is some kind of crash when running a command. I will say that I don't think we're doing a very good job handling errors, and I suspect it's that most users don't report them (they just press <Esc> and it goes back to normal).
For example, this: https://github.com/VSCodeVim/Vim/pull/2087
Either way, if you're ever interested in heading back to VSCode and felt disappointed in the Vim mode, check out the progress of https://github.com/VSCodeVim/Vim/pull/1897 or https://github.com/Chillee/VSCodeNeovim. Those should provide a much higher fidelity emulation.
For example, this: https://github.com/VSCodeVim/Vim/pull/2087
Either way, if you're ever interested in heading back to VSCode and felt disappointed in the Vim mode, check out the progress of https://github.com/VSCodeVim/Vim/pull/1897 or https://github.com/Chillee/VSCodeNeovim. Those should provide a much higher fidelity emulation.
Ah, that would certainly make sense. Is there any logging anywhere when such a thing occurs so one could help dissect the issue?
If you try opening up dev tools when that happens, it's likely the issue will pop up.
Honestly, there's several places that from an engineering quality standpoint bother me quite a bit. Performance on rapidly repeated actions is one. We have a couple race conditions too. A bunch of inproperly handled errors is another.
However, most of these don't really impact most users most of the time. If you're using vim, you're probably not holding down `dd` or rapidly typing actions one after a while. Similarly, as errors are separated into their own action and are captured at the top level, hitting escape is usually enough to get you back to a usable state.
Honestly, there's several places that from an engineering quality standpoint bother me quite a bit. Performance on rapidly repeated actions is one. We have a couple race conditions too. A bunch of inproperly handled errors is another.
However, most of these don't really impact most users most of the time. If you're using vim, you're probably not holding down `dd` or rapidly typing actions one after a while. Similarly, as errors are separated into their own action and are captured at the top level, hitting escape is usually enough to get you back to a usable state.
I stopped thinking of VS Code as an "editor" and more as a lightweight IDE and my perceptions about it changed a lot. It's still way faster / smoother than working with Atom though, and I used Atom since it came out, but it's too sluggish feeling. Also search in VS Code is powered by ripgrep which is coded in Rust, and it is blazing fast.
I’d love to see more IDEs try to address the issue of Spellcheck in code editors. Currently, you can do it by writing your own spell checker and embedding it in your language server, but this is a recipe for repeated work and inconsistent user interfaces.
FWIW, Intellij IDEs have a builtin spell checker.
And I always turn if off because it is unusable. For text it's okay but for code it's rules doesnt make any sense - concatenated words are marked as errors which is real annoying.
I believe NetBeans only spell checks comments and other 'real' language text (git commit messages?), not code itself. I'd imagine other IDEs to do the same. It's really silly if some IDE spell checks code and marks camelCase as errors.
I just tested some things in PyCharm. It has no problem with word_word or wordWord as variable names. It's even smart enough to flag just the non-word in word_ajsjasjasa.
It will also put a squiggly under camelCaseWords in Python code by default, but that's because of PEP8 style rules, not spelling.
It will also put a squiggly under camelCaseWords in Python code by default, but that's because of PEP8 style rules, not spelling.
GNOME Builder uses gspell: https://wiki.gnome.org/Projects/gspell.
I wonder what the "issue dynamic" will be in the coming months/quarters. There are currently 5000+ open issues, 3000 of them feature requests. I hope the roadmap doesn't present any new features, but it's solely working on squashing all these to bring the issue number down. Looking at the Insights page for the last month (1600 closed issues, 630 new issue), I'm remaining hopeful, but only time will tell. I originally wanted to write that VS Code needs a "Snow Leopard" iteration, but it seems that it's already underway.
Good luck to everyone on the VS Code team.
Good luck to everyone on the VS Code team.
I really like how relaxed and informal this way of presenting a roadmap is (especially coming from a corporation like Microsoft).
Also, the fact that they've identified and focused on keeping startup time low and performance high is a core point for the value of a code editor really gives me hope for VSCode. Especially that they seem to realise responsiveness and low resource usage is more valuable than blindly adding new features and extensions.
Also, the fact that they've identified and focused on keeping startup time low and performance high is a core point for the value of a code editor really gives me hope for VSCode. Especially that they seem to realise responsiveness and low resource usage is more valuable than blindly adding new features and extensions.
It's (unfortunately but understandably) marked as a stretch goal, but semantic colouring sounds really nice. I first came across the idea in this post about KDevelop: https://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from...
What's the main idea behind this?
EDIT: oh, instead of defining a color scheme with regexes (which kinda sucks), you would define colors based on the semantics given by the language service. That would be extremely nice indeed.
EDIT: oh, instead of defining a color scheme with regexes (which kinda sucks), you would define colors based on the semantics given by the language service. That would be extremely nice indeed.
The most compelling feature to me is that it can give different variables a different colour.
My sole wish for VS Code is multiline errors and warnings, as more languages adopt properly formatted errors (like Elm and Reason)
If that is really your sole wish, you should really file an issue[1] if you haven't already.
Then for bonus points, come back here and post link to it. I would support it; my team wants that, too.
[1]: https://github.com/Microsoft/vscode/issues
EDIT: there is one: https://github.com/Microsoft/vscode/issues/1927
Then for bonus points, come back here and post link to it. I would support it; my team wants that, too.
[1]: https://github.com/Microsoft/vscode/issues
EDIT: there is one: https://github.com/Microsoft/vscode/issues/1927
Yup, that’s the issue :) I even asked if it could be bumped up in priority.
Unfortunately, not yet :(
Unfortunately, not yet :(
Has configuration become any better? I tried using VS Code for both Go and Python and all the magical stuff you needed to add to JSON files in weird places became a show stopper. I simply cannot figure out how it ties together and or figure out what my configuration options are.
You edit one personal settings JSON file for all of your options. You don't have more than one file and it over rides the options so the only things in your JSON file are your options and I comment a ton about what and why they are there.
I prefer this over any gui system. I can copy and paste this and have the same options across all my machines.
I prefer this over any gui system. I can copy and paste this and have the same options across all my machines.
I don't remember that ever being the case. The settings are in settings.json, that's "how it ties together."
It opens alongside the default settings file, that's a searchable list of "what my configuration options are."
Clicking the name of the property in the default settings file copies it to your personal file with the value you select. It's even easier than Sublime to configure.
It opens alongside the default settings file, that's a searchable list of "what my configuration options are."
Clicking the name of the property in the default settings file copies it to your personal file with the value you select. It's even easier than Sublime to configure.
I also found configuration to be obnoxious when I first tried VS Code. It's better now.
It's still a JSON file, but the UI for editing it has improved a lot over the past year or so. You can search/filter the default configuration to see what options are available, and then you can just click each option to override it in your user or workspace config.
It's still a JSON file, but the UI for editing it has improved a lot over the past year or so. You can search/filter the default configuration to see what options are available, and then you can just click each option to override it in your user or workspace config.
Their roadmap says they are working on settings ui improvements. I look forward to that.
Is anyone aware of an article detailing how the VS Code team was able to realize so much performance out of Electron? VS Code is one of the most native-feeling, lightweight Electron products I've used (as compared to say, Slack) and I wonder how they got there.
Like any webapp they analyzed their paint times and made great performance improvements.
From the data structures of how they store lines and tokens of currently edited files, scrolling, refreshing changes on the screen etc they analyze perf, see what can be optimized and make it happen. Very few teams put perf above features at MS. Vscode is exceptional in that sense.
Also vscode uses processes quite a bit. The main app lives on one process, the language servers are all different processes, extensions are different processes etc. all communicating over jsonrpc
This means the main editor cannot get clogged by an extension hanging up or crashing.
From the data structures of how they store lines and tokens of currently edited files, scrolling, refreshing changes on the screen etc they analyze perf, see what can be optimized and make it happen. Very few teams put perf above features at MS. Vscode is exceptional in that sense.
Also vscode uses processes quite a bit. The main app lives on one process, the language servers are all different processes, extensions are different processes etc. all communicating over jsonrpc
This means the main editor cannot get clogged by an extension hanging up or crashing.
I have 22 years of daily vi experience. VS Code is the only visual editor that I can stomach outside of vim. I have tried sublime, eclipse and hated them. Tried emacs many occasions, but just couldn't be bothered to learn all those shortcuts.
Just in case (Sciter's author is here):
This is prototype I've made to give an idea of how the same thing could be done in Sciter: https://sciter.com/htmlcss-desktop-ui-solutions-distribution...
In general it is expected that such thing can be done in 5% of VS Code distribution size.
Sciter draws things faster than Electron as e.g. on Windows it uses DirectX directly. Electron uses Skia that is mostly CPU based rasterizer.
Yet to make syntax highlighting I've introduced "marked runs" - https://sciter.com/tokenizer-mark-syntax-colorizer/
That allows to do syntax highlighting without change of DOM. In VS Code, in order to make things at least somehow moving, they were forced to implement sliding window editing - DOM represents not full text but only viewable portion. That creates a lot of problems and significant portion of Code is the fight with limitations of browser's DOM.
This is prototype I've made to give an idea of how the same thing could be done in Sciter: https://sciter.com/htmlcss-desktop-ui-solutions-distribution...
In general it is expected that such thing can be done in 5% of VS Code distribution size.
Sciter draws things faster than Electron as e.g. on Windows it uses DirectX directly. Electron uses Skia that is mostly CPU based rasterizer.
Yet to make syntax highlighting I've introduced "marked runs" - https://sciter.com/tokenizer-mark-syntax-colorizer/
That allows to do syntax highlighting without change of DOM. In VS Code, in order to make things at least somehow moving, they were forced to implement sliding window editing - DOM represents not full text but only viewable portion. That creates a lot of problems and significant portion of Code is the fight with limitations of browser's DOM.
I really want to try VSCode, but it sends data to Microsoft even with Telemetry et al off [1].
Which is not surprising considering that Windows itself does the same thing [2] (hence, my not using Windows).
Even if they allowed us to opt-out of telemetry now, I wouldn't trust them not to silently opt us back in later.
This is not something I can accept my editor doing, and would expect a little less apathy about it from the HN crowd.
Does anyone know more about the MS spyware and how much I need to worry about it?
[1] https://github.com/Microsoft/vscode/issues/16131 [2] https://arstechnica.com/information-technology/2015/08/even-...
Which is not surprising considering that Windows itself does the same thing [2] (hence, my not using Windows).
Even if they allowed us to opt-out of telemetry now, I wouldn't trust them not to silently opt us back in later.
This is not something I can accept my editor doing, and would expect a little less apathy about it from the HN crowd.
Does anyone know more about the MS spyware and how much I need to worry about it?
[1] https://github.com/Microsoft/vscode/issues/16131 [2] https://arstechnica.com/information-technology/2015/08/even-...
> but it sends data to Microsoft even with Telemetry et al off
I think Microsoft responded 100% correctly. They stated what they were doing, proved what they did, and they were wrong and stopping it.
BTW I rather deal with a developer that is that responds this way. I also don't mind my editor sending update pings and when I have crashes which most programs are opt-out.
From 2016 > today we continue to send events stating that a user has opted out and nothing else i.e. no usage data is sent. Here is the test to ensure that is all we send... https://github.com/Microsoft/vscode/blob/master/src/vs/platf...
But we don’t need to do that and I don’t think it’s what you expect as a user – so we will stop sending anything i.e. even the opt out event Look for a change there soon.
Thanks for bringing this to our attention and I hope you enjoy working with VS Code.
I think Microsoft responded 100% correctly. They stated what they were doing, proved what they did, and they were wrong and stopping it.
BTW I rather deal with a developer that is that responds this way. I also don't mind my editor sending update pings and when I have crashes which most programs are opt-out.
From 2016 > today we continue to send events stating that a user has opted out and nothing else i.e. no usage data is sent. Here is the test to ensure that is all we send... https://github.com/Microsoft/vscode/blob/master/src/vs/platf...
But we don’t need to do that and I don’t think it’s what you expect as a user – so we will stop sending anything i.e. even the opt out event Look for a change there soon.
Thanks for bringing this to our attention and I hope you enjoy working with VS Code.
Actually, the issue link you give actually states that it doesn't if you don't want it to.
It used, at time of issue creation, that one telemetry call was still sent, to tell that you disabled telemetry.
They have since removed that call too, and the only ones left are those to the update server at startup to know if a new version is available (and one to extension market to know if extension updates exists). It can be user disabled, by disabling auto update.
I hate how Windows 10 telemetry is forced down your throat, but for vs code there is no such issue
It used, at time of issue creation, that one telemetry call was still sent, to tell that you disabled telemetry.
They have since removed that call too, and the only ones left are those to the update server at startup to know if a new version is available (and one to extension market to know if extension updates exists). It can be user disabled, by disabling auto update.
I hate how Windows 10 telemetry is forced down your throat, but for vs code there is no such issue
Most people really don't care if MS knows you opened Code, used it with JS and Python projects, and installed 3 extensions. And yeah, it makes Code much better when MS knows how you're using it, btw
Most people don't care that obtaining "real" diamonds gets people killed, doesn't make it OK.
Yep software analytics and blood diamonds are pretty equivalent.
Anything goes if it improves the product.
> Does anyone know more about the MS spyware and how much I need to worry about it?
Actually the project is open source, so rather than FUD up the conversation:
https://github.com/Microsoft/vscode/blob/master/src/vs/platf...
Actually the project is open source, so rather than FUD up the conversation:
https://github.com/Microsoft/vscode/blob/master/src/vs/platf...
This line alone shows how they don't even grasp the concept of opt-in:
this._userOptIn = typeof config.userOptIn === 'undefined' ? true : config.userOptIn;
https://github.com/Microsoft/vscode/blob/b0a7b57d46a2dc1bafe...
this._userOptIn = typeof config.userOptIn === 'undefined' ? true : config.userOptIn;
https://github.com/Microsoft/vscode/blob/b0a7b57d46a2dc1bafe...
Did you file a bug? I started to and then Laziness said, "But you don't even use VSCode..."
Check out the Ionide plugin for Fsharp on VSCode, it's really good and improves at a breakneck pace.
Does anyone know what the "Investigate into a native model layer" point might be about? It sounds very relevant to my interests, but though it is apparently ongoing, I wasn't able to find any issues or other pages referencing those terms.
I use VS Code and enjoy it very much. However, for some reason the git diff visualizer doesn't really work anymore - I have to re-open the IDE to get it to show new changes to saved files. Anyone else have this issue?
> for some reason the git diff visualizer doesn't really work anymore
Yep, exact same issue with recent releases VS Code releases on RHEL. Every few days VS Code starts diffing against an old version of the code and I have to completely exit and restart.
Yep, exact same issue with recent releases VS Code releases on RHEL. Every few days VS Code starts diffing against an old version of the code and I have to completely exit and restart.
My number one feature request for VS Code is the ability to detach multiple windows and move them around on multiple monitors.
For example I want the project sidebar thing to sit on a separate monitor.
Would be really nice.
For example I want the project sidebar thing to sit on a separate monitor.
Would be really nice.
This release cadence from MS is completely killing some internal packaging operations at big corps I've worked at.
(For those who don't know, applications are typically QA-ed and packaged so they can be automatically requested and deployed via MS SMS or whatever the latest version is. No downloading .exe)
Typically this packaging process takes longer than it does MS to release a new version. They're in a constant state of catch-up, and it's frustrating for developers that want the latest and greatest version.
(For those who don't know, applications are typically QA-ed and packaged so they can be automatically requested and deployed via MS SMS or whatever the latest version is. No downloading .exe)
Typically this packaging process takes longer than it does MS to release a new version. They're in a constant state of catch-up, and it's frustrating for developers that want the latest and greatest version.
This speaks more about enterprise "packaging process". Why can't they let the devs manage their own machines? This is one big reason devs love Macbooks, because OSX just doesn't allow the employer to fuck around with the machine a lot.
"Why can't they let the devs manage their own machines?"
Part of the problem is that then the devs aren't actually managing the systems, they are blindly trusting the vendors. To a large extent, (re)packaging is make-work that should not need to happen, but it does provide a kind of safety fuse. In the event that a vendor breaks something or worse, unilaterally decides to change the product, organizations needs to be able to put a stop on new versions. The change of icons on VS Code was a trivial misstep, but it demonstrates that the VS Code team has the power to push changes that that users do not actually want on to large numbers of systems.
It is the same dynamic as the snap/flatpak vs. Linux distribution packaging debate. Most of the time, the developer can deliver their software faster, more reliably, and with better QA, if they are given a direct pipeline to user desktops. Sometimes, though, they will screw up, or they will make a decision that works for them, but not their users.
Part of the problem is that then the devs aren't actually managing the systems, they are blindly trusting the vendors. To a large extent, (re)packaging is make-work that should not need to happen, but it does provide a kind of safety fuse. In the event that a vendor breaks something or worse, unilaterally decides to change the product, organizations needs to be able to put a stop on new versions. The change of icons on VS Code was a trivial misstep, but it demonstrates that the VS Code team has the power to push changes that that users do not actually want on to large numbers of systems.
It is the same dynamic as the snap/flatpak vs. Linux distribution packaging debate. Most of the time, the developer can deliver their software faster, more reliably, and with better QA, if they are given a direct pipeline to user desktops. Sometimes, though, they will screw up, or they will make a decision that works for them, but not their users.
Well, I do appreciate the service that distributions do.
In Debian everything has a manpage, even if upstream does not provide one and things install into the right directories and integrate into the system well.
If for instance Chromium adds some phone home functionality, I trust that it will be patched out...
The homebrew debacle has shown me that today's "open source" developers don't care about their user's privacy.
If for instance Chromium adds some phone home functionality, I trust that it will be patched out...
The homebrew debacle has shown me that today's "open source" developers don't care about their user's privacy.
There are enterprise solutions for macOS management.
Oh yes, I don't disagree. I think it would be good if they could at least do a "light QA" for trusted corporations - MS, Google etc.
And no devs at the corps I've worked at (big banks) have Macbooks for coding. If they do, it will just be connecting to a VM somewhere.
And no devs at the corps I've worked at (big banks) have Macbooks for coding. If they do, it will just be connecting to a VM somewhere.
I like VS Code. Been using it for a few months now. Would be nice if it started up faster though. Sometimes I still use sublime just to quickly open a single file.
For javascript, typescript etc VS code is excellent. For simple hacking I still use vim a lot, and for medium side projects I just open geany which is light and fast and does the job fairly well.
At the moment for web related work I use vscode, otherwise I still keep coming back to vim and geany, which are light-weight, quick and get the job done.
Geany is truly excellent, I hope it can keep evolving as it has been for many years.
At the moment for web related work I use vscode, otherwise I still keep coming back to vim and geany, which are light-weight, quick and get the job done.
Geany is truly excellent, I hope it can keep evolving as it has been for many years.
I tried VS Code for a while and the vim integration is really good. Unfortunately it's just not-quite-there IMO. I have a few muscle-memory things like ":tabe foo<tab>" that breaks when I try the tab completion (and IIRC it does something irritating like moving focus).
The problem with `cmdline` modes is definitely that tab completion doesn't work imo. Unluckily, that's blocked on the VSCode side, although it is possible to move our cmdline down to the status bar (probably would have been the better choice to begin with, really).
For example, with the neovim rewrite it's possible to expose not only tab completion, but also the wildmenu: https://imgur.com/DO6IXYb
If we wanted to keep it in the input box that pops up, we would need something along these lines: https://github.com/Microsoft/vscode/pull/36690 (it is my PR, for disclosure).
For example, with the neovim rewrite it's possible to expose not only tab completion, but also the wildmenu: https://imgur.com/DO6IXYb
If we wanted to keep it in the input box that pops up, we would need something along these lines: https://github.com/Microsoft/vscode/pull/36690 (it is my PR, for disclosure).
Very sad to see that printing isn't on the roadmap for next year.
If others want this feature, it's tracked in https://github.com/Microsoft/vscode/issues/5953
If others want this feature, it's tracked in https://github.com/Microsoft/vscode/issues/5953
I really want support for multiple monitors!
Still no first-class SFTP support. Doesn't look like I'll try VS Code until at least 2019.
Is "Continue to invest into API that enables remote development" not what you want?
Why does an editor need SFTP support?
Is this similar to Zawinski's law of software denvelopment?
Is this similar to Zawinski's law of software denvelopment?
Very interested in the language server protocol aspect of this.
There's Sourcegraph editor based on it, although it's still in beta https://about.sourcegraph.com/products/editor/
This is a great python IDE for Linux.
I wouldn't say its an IDE it just a really powerful editor and the RUN plugin is awesome.
You've got an editor, a task runner to handle builds, a debugger, code completion, what else do you need to call it an IDE?
The regular Visual Studio uses about the same amount of memory as VSCode while being an order of magnitude more complex and feature-rich.
The question I'm wondering about is what is Microsoft's end game with this? I'm comparing this to the history of Google Chrome that, when released, was similar in the sense that it was better than the alternatives: wickedly fast, open sourced, with no apparent strings attached. The business benefits to Google and market control from owning Chrome are obvious today and I'm trying to understand the long term view in VSCode - i.e how to you eventually create business value from a free editor? Premium features? Better integration with Microsoft's services? I wonder if there's a deeper vision - I mean, as opposed to Chrome, VSCode does not know much about me personally, does not provide much data to further leverage Microsoft's services, and targets a much narrower audience to begin with. So, what's the business model behind it's development. I'm too much of a skeptic to believe it's just so developers have a warm fuzzy feeling associated with Microsoft...