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

31–40 of 236 posts

Re: VS Code Roadmap 2018

#31

Post by davedx »

veidr wrote: post #5
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.

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?

Re: VS Code Roadmap 2018

#32

Post by sandos »

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, 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!

Re: VS Code Roadmap 2018

#33

Post by pjmlp »

sandos wrote: post #32
pjmlp wrote: post #16

Earlier quoted context omitted.

It is surely faster than Atom, but not on the same league as sublime, emacs or vim.

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…

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.

Re: VS Code Roadmap 2018

#34

Post by antod »

nerdponx wrote: post #15
slimsag wrote: post #13

Earlier 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?

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.

Re: VS Code Roadmap 2018

#35

Post by calcifer »

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.

Re: VS Code Roadmap 2018

#36

Post by throwaway613834 »

SaturateDK wrote: post #14
xfer wrote: post #11

Earlier quoted context omitted.

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.

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

Re: VS Code Roadmap 2018

#37

Post by chuckdries »

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…

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.

Re: VS Code Roadmap 2018

#38

Post by pjc50 »

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)

Re: VS Code Roadmap 2018

#39

Post by smcl »

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?

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.

Re: VS Code Roadmap 2018

#40

Post by sambeau »

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)

Post reply on HN