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

51–60 of 236 posts

Re: VS Code Roadmap 2018

#51

Post by chrismbarr »

sambeau wrote: post #40

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…

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!

Re: VS Code Roadmap 2018

#52

Post by SiVal »

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

Re: VS Code Roadmap 2018

#53

Post by tstieff »

kasparsklavins wrote: post #42
calcifer wrote: post #35

Earlier quoted context omitted.

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.

It tends to work best with Java conventions, so camelCase spellings are interpreted correctly, but other conventions - not so much.

Re: VS Code Roadmap 2018

#54

Post by Already__Taken »

sambeau wrote: post #40

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…

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.

Re: VS Code Roadmap 2018

#55

Post by rkachowski »

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.

Re: VS Code Roadmap 2018

#56

Post by throwaway613834 »

barrkel wrote: post #50
throwaway613834 wrote: post #43

Earlier quoted context omitted.

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

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

Re: VS Code Roadmap 2018

#57

Post by FRex »

kasparsklavins wrote: post #42
calcifer wrote: post #35

Earlier quoted context omitted.

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.

Re: VS Code Roadmap 2018

#58

Post by baldfat »

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…

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

Re: VS Code Roadmap 2018

#59

Post by baldfat »

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…

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.

Re: VS Code Roadmap 2018

#60

Post by baldfat »

antod wrote: post #34
nerdponx wrote: post #15

Earlier quoted context omitted.

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.

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.
Post reply on HN