Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VS Code Roadmap 2018

github.com

Post reply on HN
Print view View original

41–50 of 236 posts

Re: VS Code Roadmap 2018

#41

Post by barrkel »

throwaway613834 wrote: post #36
SaturateDK wrote: post #14

Earlier quoted context omitted.

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".

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

Re: VS Code Roadmap 2018

#42

Post by kasparsklavins »

calcifer wrote: post #35
moomin wrote: post #18

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.

Re: VS Code Roadmap 2018

#43

Post by throwaway613834 »

barrkel wrote: post #41
throwaway613834 wrote: post #36

Earlier quoted context omitted.

> 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".

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…

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.

Re: VS Code Roadmap 2018

#44

Post by sam_goody »

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-...

Re: VS Code Roadmap 2018

#45

Post by mrweasel »

davedx wrote: post #31
veidr wrote: post #5

Earlier quoted context omitted.

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 t…

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.

Re: VS Code Roadmap 2018

#46

Post by barrkel »

pjmlp wrote: post #16
pbiggar wrote: post #12

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…

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.

Re: VS Code Roadmap 2018

#47

Post by m_fayer »

pjc50 wrote: post #38
ssijak wrote: post #3

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.

Well, the regular Visual Studio is a native app and has terrible performance and memory usage too. (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.

Re: VS Code Roadmap 2018

#48

Post by mrweasel »

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.

Re: VS Code Roadmap 2018

#49

Post by hudo »

sam_goody wrote: post #44

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 fr…

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

Re: VS Code Roadmap 2018

#50

Post by barrkel »

throwaway613834 wrote: post #43
barrkel wrote: post #41

Earlier quoted context omitted.

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…

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...

Post reply on HN