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

Visual Studio Code 1.6

code.visualstudio.com

Post reply on HN
Print view View original

201–210 of 231 posts

Re: Visual Studio Code 1.6

#201

Post by astrostl »

I love VSC, and use it for Python.

It's the only GUI editor that's ever "stuck" for me, having bought Textmate, tried Sublime, etc. Always go back to CLI Vim. I'm coming from the perspective of someone that hates IDEs, and only wants a bit more than what Vim provides in terms of battery inclusion. I think VSC's level of Git integration, for example, is perfect for me. Handle the common stuff, drop to the CLI for the rest. Extensions, especially relative to Sublime, also perfect for me.

The rate of improvement, while obviously a draw, only manages to give me fear that it's going to turn into IDEA or whatever, nested menus upon menus of corner-case features that I will never, ever use. My brand of minimalism actually makes me wish they would slow down :P

Re: Visual Studio Code 1.6

#202

Post by Already__Taken »

kwood wrote: post #195
Already__Taken wrote: post #190

Earlier quoted context omitted.

Other commenters aren't answering this. ctrl+` hides or opens the terminal. If you want to leave it open there's no command to toggle only your cursor focus from editor to terminal. edit: I take it back, It's just not bound.{"key": "ctrl+#", "command": "workbench.action.terminal.focus"} But you can't move the focus back with that toggle. https://code.visualstudio.com/docs/editor/integrated-termina...

Good point! I already have double pressing the terminal toggle in my muscle memory, using focus might be worth changing that habit. To "get out" of the terminal, cmd+1 sets focus on the editor again (to be precise: focus on the first editor group if there is a split view).

Ooh good spot. Thank you.

Re: Visual Studio Code 1.6

#203

Post by PeCaN »

elnado wrote: post #146
PeCaN wrote: post #120

Earlier quoted context omitted.

Why would you rewrite already-working services written in an expressive and battle-tested language to a fad 1970s-style language? It's like being in the late 90s and replacing your existing infrastructure with Java hype, except with a language somehow worse but justified with Rob Pike's pseudointellectual bullshit.

Haha fair argument. As someone pointed out - it's very easy to incur technical debt in Perl. It's a dynamic language with virtually non-existant dev tools and lacking open source community. I personally can't wait to go back to a static language for our backend. We're looking at NodeJS (of course...), JVM, and Go. Arguably you can fake typing in NodeJS with TypeScript, Flow, etc, but my team isn't too excited about J…

Fair, and good response. I was kind of just venting about my general dislike for Go there….

I do think Go has a decent niche for backend services similar to Erlang but with a much easier learning curve (and more available talent). Sounds like you're actually using the right tool for the right job.

Re: Visual Studio Code 1.6

#205

Post by problems »

ygra wrote: post #169
Matthias247 wrote: post #153

Earlier quoted context omitted.

I don't have any scaling issues on my Win10 4k 175% scaling setup. But unfortunately text rendering is still blurry compared to native editors due to the underlying Electron/Chromium renderer. Hope this will get resolved soon :'( https://github.com/Microsoft/vscode/issues/1896

I guess that's what they meant. While the scaled-up result has the correct size and avoids other artifacts of broken high-dpi rendering, it's, well, blurry. However, I suspect that this is more a Chromium/Electron issue than one for VS Code and other applications built like that. Heck, not even Chrome scales properly on high-dpi displays, which is pretty poor in my eyes.

Hmm, Chrome looks perfectly fine on my high-DPI display (4k 150%), but both Atom and VSCode have major issues. Possibly an Electron issue I suppose, but I can't say for certain. Pretty ridiculous that almost every other app I run scales perfectly now, but text editors don't. Of course, Emacs, Notepad++ and Sublime all work perfectly so it doesn't impede me much.

Re: Visual Studio Code 1.6

#206

Post by rayiner »

Cyph0n wrote: post #36
david-given wrote: post #20

Earlier quoted context omitted.

I'm currently switching from gvim to vscode and back again every five minutes, in order to use vscode's debugger --- it's gdb integration is the best I've seen bar none [1][2]. If the vim emulation was good enough, I'd switch in a moment. Which, unfortunately, it's not, for me: the biggest omission is shift-Y/shift-P for yank and paste, which I use constantly, but there's holes everywhere. (Also, the way the vscode's…

Damn, seriously? I'm going to be writing some C++ soon, and I'm also planning to learn gdb, so I guess VS Code it is then. Thanks for the heads up!

VSCode's C++ plugin supports both gdb and lldb (at least on macOS). As for what to learn--I'd learn GDB. Pretty much every architecture on the planet has a GDB port.

Re: Visual Studio Code 1.6

#208

Post by saosebastiao »

frutiger wrote: post #94
johnfn wrote: post #53

Earlier quoted context omitted.

Hi! I'm one of the core developers of VSCodeVim. Shift-Y and Shift-P absolutely work for me, so please report on our issues page if they continue to not work for you: https://github.com/VSCodeVim/Vim/issues I would also be really interested to hear about the other holes that you're running into. Always trying to make a better Vim experience for you :)

I don't wish to derail the thread, but while I have your ear: is there any hope for using the neovim over its msgpack interface instead of implementing vim bindings from scratch?

Whoa. Never even thought about this, but it would be completely awesome.

Speaking of Neovim, it sure would be nice to have a special mode specifically for yielding to an IDE so that all of the IDE's default keybindings can remain intact.

Re: Visual Studio Code 1.6

#209

Post by turtle4 »

headmelted wrote: post #147

I've been working lately on getting Visual Studio Code to compile for ARM. Its working fairly reliably but Travis doesnt support the toolchain so Im having to use Gitlab CI in the meantime. I want to give this a little more polish before I release, but can I gauge from the folks here if there would be any interest in ARM nightlies for Raspberry Pi (and other ARM SBCs)/ARM Chromebooks? If so, I'll move some things aro…

I would love to see in on rpi3 as an alternate editor for python, node, go if it could be performant.

Re: Visual Studio Code 1.6

#210

Post by tsaprailis »

kwood wrote: post #195
Already__Taken wrote: post #190

Earlier quoted context omitted.

Other commenters aren't answering this. ctrl+` hides or opens the terminal. If you want to leave it open there's no command to toggle only your cursor focus from editor to terminal. edit: I take it back, It's just not bound.{"key": "ctrl+#", "command": "workbench.action.terminal.focus"} But you can't move the focus back with that toggle. https://code.visualstudio.com/docs/editor/integrated-termina...

Good point! I already have double pressing the terminal toggle in my muscle memory, using focus might be worth changing that habit. To "get out" of the terminal, cmd+1 sets focus on the editor again (to be precise: focus on the first editor group if there is a split view).

Yes, thanks very much! I actually had those too, as a backup but I think different combinations for opening and closing (or in this case toggling into terminal, and back into the editor) are more cumbersome than simply opening/closing.
Post reply on HN