Live data from Hacker News

VS Code can do that?

vscodecandothat.com

111–120 of 280 posts

Re: VS Code can do that?

#111
post #20
post #18

Really nice idea, but 90% focused on Web (frontend?) development. HTML, JS, and not much else. :( Still found 2 useful things for me, Parens colorizer and settings sync via Github Gist.

I use it for most of my C++ projects, and it almost does a better job than Visual Studio itself.

I like the idea of using VS Code for my C and C++ work but last time I looked at it I lost interest looking at the length of the setup page for tasks.json and all that to get a C++ build toolchain configured. Is this still the case? Why can it not be more automatic like pretty much every other editor for supporting GCC or cl.exe?

What is your setup? Is it system wide or do you configure it manually for each project/workspace/folder?

Re: VS Code can do that?

#112
post #28
post #16

Earlier quoted context omitted.

What is your workflow like that a few second delay is a major blocker? I used to feel the same way early in my career. Now I don’t feel the need to be in a rush all the time.

I've seen some people make the argument that they want to use their editor for quick edits to single files, which is a fine use-case. However, VS Code is really not designed to be optimized for that case. It's really about editing code (hence the name) as opposed to quick edits to configs, etc. It's usually best if one knows a few different tools designed for different scenarios. Right tool for the job.

I leave vscode open basically 100% of the time and use notepad++ for quick edits. Vscode having slow startup doesn't affect my support of it at all

Re: VS Code can do that?

#113
post #61

Slightly off topic but this code in example #5: get() { return new Promise((resolve, reject) => { fetch(`${baseAPI}/heroes`) .then(response => response.json()) .then(json => resolve(json)) .catch(err => { reject (err); }); }); } Why not just: get() { return fetch(`${baseAPI}/heroes`) .then(response => response.json()); }

That has fewer brackets to colorize.

Re: VS Code can do that?

#114
post #61

Slightly off topic but this code in example #5: get() { return new Promise((resolve, reject) => { fetch(`${baseAPI}/heroes`) .then(response => response.json()) .then(json => resolve(json)) .catch(err => { reject (err); }); }); } Why not just: get() { return fetch(`${baseAPI}/heroes`) .then(response => response.json()); }

[deleted]

Re: VS Code can do that?

#115

Some other ones: - In the Git view, select a modified file, select some lines of code you modified, cmd shift P, Git: Stage Selected Ranges. I dropped my dedicated Git GUI since I know this trick. - If you spend a lot of time coding in React, and have half of your files named index.js, do yourself a favor, go in the settings and add "workbench.editor.labelFormat": "short" (display the name of the file's folder in all…

I keep hearing good things about VSCode. If I weren't essentially married to emacs I'd definitely try it out. I'm not sure I'd recommend emacs to everyone at this point, though I think it remains a really solid choice of editor/OS for people willing to get over the learning curve and put up with a bit of clunkiness.

Re the git stuff though- one place that I'm pretty sure emacs is the uncontested champ is in git integration via magit. I'd be inclined to recommend using emacs as their git interface even to people who want to use a different interface for everything else. It is that good, and IMHO the only git porcelain that is strictly better than the standard git porcelain.

Re: VS Code can do that?

#116
post #59

Earlier quoted context omitted.

And here I am using for loops like a caveman

I think loop unrolling is super cool. We're typically trained in programming to try to eliminate the kind of reuse that unrolling typically looks like, but when applied properly it can work really well. I guess that applies to most tools, though.

Can you give us an example where manual loop unrolling would be desired over a for loop?

Re: VS Code can do that?

#118
post #50
post #25

If only the core was some sturdy C++ or Rust or whatever as opposed to JS and a nice GUI/Canvas lib as opposed to DOM.

Why? It works well and it's allowed them to develop it incredibly quickly.

Well, ST3 does 70% of what VSCode does, at 1/10th the memory and much faster, and it's written by a single person.

Besides, they're still writing in a typed "language" (ts), so it's not like the dynamic language nature of JS that allows the VSCode base code to be developed incredibly quickly.

What really allows them to develop it incredibly quickly is the plugin API -- which allows tons of npm stuff to be ported and tons of JS programmers to create plugins for VS Code. A native statically typed based core would allow for that too. In fact the VSCode team already have moved some VSCode processing to C++ libs exactly for speed (and of course node itself is C++).

Using DOM for the drawing is faster (for a convenience perspective, not execution speed) yes, but with MS resources they could have made a streamlined equivalent that's much faster, more memory efficient, and doesn't have all the baggage of a web rendering engine. In fact, they have several native alternatives lying around they could make cross platform.

As it is, VSCode will ever have the burden of rendering to the DOM.

Re: VS Code can do that?

#119

Earlier quoted context omitted.

People actually use "work deletion mode" on purpose? I've always wished this key at least had an LED indicator along with Caps Lock.

Once upon a time, hitting insert resulted in the caret switching from line to rectangle to indicate input mode.

It used to be that normal mode was an underline cursor and insert mode was a vertical cursor, but now that I guess vertical cursors are everywhere, Sublime switches between a vertical cursor for normal mode and an underline cursor for insert mode. A bit of a drag, but I don't use insert much at all.

One thing I'd like from the past is a blinking block cursor.

Re: VS Code can do that?

#120
post #115

Some other ones: - In the Git view, select a modified file, select some lines of code you modified, cmd shift P, Git: Stage Selected Ranges. I dropped my dedicated Git GUI since I know this trick. - If you spend a lot of time coding in React, and have half of your files named index.js, do yourself a favor, go in the settings and add "workbench.editor.labelFormat": "short" (display the name of the file's folder in all…

I keep hearing good things about VSCode. If I weren't essentially married to emacs I'd definitely try it out. I'm not sure I'd recommend emacs to everyone at this point, though I think it remains a really solid choice of editor/OS for people willing to get over the learning curve and put up with a bit of clunkiness. Re the git stuff though- one place that I'm pretty sure emacs is the uncontested champ is in git integ…

I wholeheartedly agree: Magit is that good, really. The way I see it, it reduces the burden associated with carrying the required git mental model in your mind, by giving you easier points of entry into its complexity. I owe all the slightly more advanced things I now routinely do with git (which would probably be seen as pretty basic by a lot of people though) to Magit, without question.
Post reply on HN