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

Integrated Terminal Performance Improvements

code.visualstudio.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Integrated Terminal Performance Improvements

#51

Post by lobster_johnson »

seanmcb wrote: post #21
w0utert wrote: post #11

I really wish Microsoft had used a different platform to build VS code on, like C#/Mono, Java, anything except Javascript/Electron basically. I just started using VS code for C++ development, trying to switch from Vim, an I basically like everything about the concept, but the execution and quality/polish of the software is mediocre at best. At least three times a day random stuff breaks: code completion stops working…

Hi @w0utert I work in the VS Code team - the experience you are having is not the experience we aspire to. It would be great to dig into this a little more and see what we can learn. Perhaps the easiest way to have a deeper dialogue is via a GitHub issue. The easiest path to creating one is leveraging 'help->report issue' that will include some additional context that will help us dig in a little more.

As I point out in a sibling comment, reporting aberrant behaviour can be difficult because the cause is usually unclear. Why is Code Helper using 100% CPU? Who knows. It happens every few days and doesn't seem be related to anything specific I do. More tools (such as a "task manager" similar to Chrome's) to gain visibility into what VSCode is doing would help here.

Re: Integrated Terminal Performance Improvements

#52

Post by lobster_johnson »

nwrk wrote: post #25
Waterluvian wrote: post #19

What's the case for using the terminal in VSCode? I use a modern multitasking computer where VSCode is in one area or screen and my terminal in another (and other things in others). By using my own terminal I get to keep everything custom about that terminal rather than having another one. Surely there's reasons that I'm missing? Edit: thanks for all the responses. A lot of great new things I didn't think of before!

For example, you can use linter in terminal which makes click on output messages interactive -> going directly to source code. edit: quick youtube example how it works together https://www.youtube.com/watch?v=cMrDePs86Uo

Wouldn't it be better to run the linter in the background and have the editor mark the problem lines? I have keyboard shortcuts bound to "next marker" and "previous marker" so I can jump to the next problem.

They don't work across an entire workspace, sadly, and I have an outstanding Github issue about it that has not seen any activity for years. Project-wide linting is something that VSCode really lacks right now. For example, it's easy to change something in one file that breaks another file, but you won't get any error markers until you go to the broken file.

Re: Integrated Terminal Performance Improvements

#53

Post by lobster_johnson »

Tyriar wrote: post #17
dy wrote: post #13

Love the integrated terminal in VS Code! Great work by the team on this and appreciate the writeup. Curious what keyboard shortcut people use to move focus from editors to the Terminal and create new terminals? Anyone use tmux inside terminal?

Author of the blog post here. The standard shortcuts are ctrl+` for toggling the panel and ctrl+shift+` for creating a new terminal. This is what I use on top of that: { "key": "ctrl+`", "command": "workbench.action.terminal.focus", "when": "!terminalFocus" } This will focus the terminal if the focus is anywhere else, if the terminal is focused it will close it. You can add this one if you want ctrl+` to only toggle…

Last I checked, this only makes sense on US keyboards. On most non-US keyboards, the backtick requires option/alt and isn't practical as a shortcut.

Re: Integrated Terminal Performance Improvements

#54

Post by lobster_johnson »

FBISurveillance wrote: post #2

Obligatory comment: I really like VSCode but keep jumping back and forth between it and Sublime because of startup time. I like VSCode enough to use it daily and extensively and jump back to sublime when I need to jump around projects fast–when startup time becomes crucial. I believe they will solve this issue at some point.

While VSCode is great, it's also useless as $EDITOR.

It's very slow to start (when it's already running), and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible. It can open the new tab, but it never relinquishes control, at least not for me.

Wouldn't be an issue if startup was super fast with "code -w", but creating new windows, even when VSCode is running, takes several seconds.

So I still use "joe" as $EDITOR.

Re: Integrated Terminal Performance Improvements

#55

Post by lobster_johnson »

simlevesque wrote: post #36
copperx wrote: post #34

Earlier quoted context omitted.

Having never looked at the source, I'm curious about how you build an editor using web technologies. Is it just a big textarea that gets manipulated with JS?

It's not one large textarea. There is a textarea which is 1x1 and right next to the cursor. I have no idea what they are for. Just open the dev tools and have some fun. You'll learn a lot.

The textarea is to accept input, presumably. It's a trick often used in a normal browser HTML page, too. You get focus, keypresses, copy/paste, etc. via the native browser UI. It's a shame that HTML doesn't provide something similar, but as a hack it's not too bad.

Re: Integrated Terminal Performance Improvements

#56

Post by chowyuncat »

santaclaus wrote: post #47
nwienert wrote: post #35

Earlier quoted context omitted.

Look at the past threads for releases (I wont link, but) they are filled with nothing but praise. I'm totally non-affiliated with VSCode, but switched from Atom a few months ago and yes, anecdotally it's been an amazingly smooth experience. I am actually the opposite of you: totally thankful for JS and electron, and I think they are the best possible future for apps. To be honest, I really think people have an emotio…

> it's a no-brainer to choose JS for just about any complex UI Javascript? Sure. Electron? Maybe not. Show me an Electron app with load times that aren't measured in seconds. Or an Electron-based text editor that doesn't choke on a moderately sized text file. VS Code is currently taking half a gig of ram on my notebook with three text files open... I happen to quite like VS Code, but to claim that Electron is a no-br…

VS Code doesn't seem to choke to moderately sized files. There is a large amount of non-Electron code used for its text editor.

Re: Integrated Terminal Performance Improvements

#57

Post by Tyriar »

lobster_johnson wrote: post #51
seanmcb wrote: post #21

Earlier quoted context omitted.

Hi @w0utert I work in the VS Code team - the experience you are having is not the experience we aspire to. It would be great to dig into this a little more and see what we can learn. Perhaps the easiest way to have a deeper dialogue is via a GitHub issue. The easiest path to creating one is leveraging 'help->report issue' that will include some additional context that will help us dig in a little more.

As I point out in a sibling comment, reporting aberrant behaviour can be difficult because the cause is usually unclear. Why is Code Helper using 100% CPU? Who knows. It happens every few days and doesn't seem be related to anything specific I do. More tools (such as a "task manager" similar to Chrome's) to gain visibility into what VSCode is doing would help here.

For excessive Code Helper CPU usage, you should be able to surface what the file/arguments were used to launch a Code Helper instance (how you do this depends on the OS). That will tell exactly which component is acting up, eg. TypeScript, search, terminal, extension, etc.

Re: Integrated Terminal Performance Improvements

#58

Post by Tyriar »

lobster_johnson wrote: post #54
FBISurveillance wrote: post #2

Obligatory comment: I really like VSCode but keep jumping back and forth between it and Sublime because of startup time. I like VSCode enough to use it daily and extensively and jump back to sublime when I need to jump around projects fast–when startup time becomes crucial. I believe they will solve this issue at some point.

While VSCode is great, it's also useless as $EDITOR. It's very slow to start (when it's already running), and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible. It can open the new tab, but it never relinquishes control, at least not for me. Wouldn't be an issue i…

> and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible.

Exactly this is actually coming in v1.17.

Re: Integrated Terminal Performance Improvements

#59

Post by lobster_johnson »

Tyriar wrote: post #57
lobster_johnson wrote: post #51

Earlier quoted context omitted.

As I point out in a sibling comment, reporting aberrant behaviour can be difficult because the cause is usually unclear. Why is Code Helper using 100% CPU? Who knows. It happens every few days and doesn't seem be related to anything specific I do. More tools (such as a "task manager" similar to Chrome's) to gain visibility into what VSCode is doing would help here.

For excessive Code Helper CPU usage, you should be able to surface what the file/arguments were used to launch a Code Helper instance (how you do this depends on the OS). That will tell exactly which component is acting up, eg. TypeScript, search, terminal, extension, etc.

This may be a recent change? The last time I tried reporting excessive CPU usage, the Code Helper process didn't have any context info in the command line.

Re: Integrated Terminal Performance Improvements

#60

Post by lobster_johnson »

Tyriar wrote: post #58
lobster_johnson wrote: post #54

Earlier quoted context omitted.

While VSCode is great, it's also useless as $EDITOR. It's very slow to start (when it's already running), and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible. It can open the new tab, but it never relinquishes control, at least not for me. Wouldn't be an issue i…

> and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible. Exactly this is actually coming in v1.17.

Awesome. Of course, fast window startup would be even better.
Post reply on HN