I really want support for multiple monitors!
VS Code Roadmap 2018
101–110 of 236 posts
Re: VS Code Roadmap 2018
#102VS 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…
> 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…
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: VS Code Roadmap 2018
#103Check out the Ionide plugin for Fsharp on VSCode, it's really good and improves at a breakneck pace.
Re: VS Code Roadmap 2018
#104Earlier quoted context omitted.
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.
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.
Re: VS Code Roadmap 2018
#105Earlier quoted context omitted.
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.
For some reason people still consider startup time a metric worth paying attention to
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.
Re: VS Code Roadmap 2018
#106Earlier quoted context omitted.
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.
Re: VS Code Roadmap 2018
#107Earlier quoted context omitted.
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?
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 (no…
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.
Re: VS Code Roadmap 2018
#108Has 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.
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.
Re: VS Code Roadmap 2018
#109A free, powerful, open sourced editor and IDE constantly improving and growing - what's not to like? - I get that some don't like the electron-based thing/performance but it never bothered me (and I bought and use both Sublime 2 & 3) - 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 n…
> 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.
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.
Re: VS Code Roadmap 2018
#110Earlier quoted context omitted.
> 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.
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).