VS Code Roadmap 2018
github.com
github.com
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...
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.
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.
Still get syntax highlighting and everything, but waiting for VS Code can be long enough to derail my train of thought.
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.
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 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.
Even still 2 seconds is too long for quick edits.
It’s noticeable but is it really that much of an issue?
Damn, I love me them multiple cursors.
Define large too - several mb? Or several 100?
Maybe you’re just an outlier?
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.
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.
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.
I stopped using VisualStudio in favor of Code in regards of .NET Core development.
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.
lucky for me it's all unnoticeable.
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.
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.
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...
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.
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.
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.
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
Ultimately I think it’s familiarity and a subtle fear that learning any new system will be a time sink.
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.
You are clearly not an Emacs user.
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 thought only the vim users used that refrain. vim users are also unlikely to switch to a different editor.
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 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 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 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.
Can’t imagine them each having a desktop app. I would just get lost switching tabs.
(Nice and related is that you can do Super+<n> for window switching in at least Windows and Ubuntu.)
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
Basically a very thin wrapper over the systems web view.
- 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.)
And yes, Chrome, at least on windows, has an `--app` switch.
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.
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 :)
Since when is Electron running a web view a native application?
By the way checkout GitLens on VS Code.
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)
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.
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.
I tried asking them on Twitter and the reply was ‘magic’.
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 wrote up an explanation for some of the other columns a few years back: https://stackoverflow.com/a/2031886/3712
Here's another article with more recent details: http://blogs.microsoft.co.il/sasha/2016/01/05/windows-proces...
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 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.
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.
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...).
(joking but also serious)
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.
Its the main reason I'm excited about Rider.
>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.
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)
Do you mean because it selects the rectangle? Just hit an arrow key.
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 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.
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! :)
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....
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 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.
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?
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 :)
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.
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."
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.
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).
vim, on the other hand, is supposed to be really quick as far as I have heard!
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 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'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.
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.
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.
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 :/
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.
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.
It will also put a squiggly under camelCaseWords in Python code by default, but that's because of PEP8 style rules, not spelling.
Good luck to everyone on the VS Code team.
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.
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.
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
Unfortunately, not yet :(
I prefer this over any gui system. I can copy and paste this and have the same options across all my machines.
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 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.
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.
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.
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-...
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.
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
Actually the project is open source, so rather than FUD up the conversation:
https://github.com/Microsoft/vscode/blob/master/src/vs/platf...
this._userOptIn = typeof config.userOptIn === 'undefined' ? true : config.userOptIn;
https://github.com/Microsoft/vscode/blob/b0a7b57d46a2dc1bafe...
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.
For example I want the project sidebar thing to sit on a separate monitor.
Would be really nice.
(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.
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.
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.
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.
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.
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).
If others want this feature, it's tracked in https://github.com/Microsoft/vscode/issues/5953
Is this similar to Zawinski's law of software denvelopment?
Maybe he wants remote editing support, which is a nice a feature for an editor to have.