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

31–40 of 74 posts

Re: Integrated Terminal Performance Improvements

#31

Post by simlevesque »

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

This is a real time saver.

Re: Integrated Terminal Performance Improvements

#33

Post by batmansmk »

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!

- You open a project, the terminal is already set in the working directory of your project. It saves you to have to cd to the right directory.

- When you debug, you see the logs of your server at the same time as the stack trace, the breakpoints without having to play with the windows.

- you can put in the vscode project some developers command, like linting, building, launching in debug mode... adding buttons to your interface to run them.

- No need to start two programs, close two programs that you always use together.

Re: Integrated Terminal Performance Improvements

#34

Post by copperx »

altano wrote: post #18
polskibus wrote: post #9

That's great! Does anyone know if the code editor itself uses canvas rendering? If not then why?

It doesn’t use canvas

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?

Re: Integrated Terminal Performance Improvements

#35

Post by nwienert »

w0utert wrote: post #22
CJefferson wrote: post #12

Earlier quoted context omitted.

Something is seriously wrong with your setup. I know many vscode users, and none of them are having your problems. I'm not saying you aren't having real problems, but they aren't common and they can appear in any editor -- I used to fill vim with plugins and it would hang frequently.

My setup is just the official, latest release, with the Microsoft plugin for C++, the Vim bindings everyone uses, and one additional plugin for switching between header and source. I customized nothing besides a few keybindings and enabling neovim mode. This is on Ubuntu by the way. I also used VS code a little on macOS for web development, and to be fair, I didn’t run into any of these problems there. But that’s for…

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 emotional reaction to JS/Electron one because it's seen as a threat to their preferred language, and two because it has all this built up hate due to legitimate past problems. A few years of pretty hectic pace in JS-land and now it's close to greatness, but still very inconsistent, so people still love to hate it. Couple that with some poorly made apps (looking at you Spotify/Slack) and you have a weird sect on HN that now vilifies Electron/JS with totally incorrect arguments about stability and speed (both are very doable with modern practices).

I'm not saying you are this person, or your grievances aren't real. But I'd be happy to put some money on the following points:

1. Electron/JS apps will be more prolific in the next 5 years

2. They will also be clearly the best platform for speed, stability and flexibility due to massive and ever improving ecosystems and dev tools.

Both have been happening, and to be honest, today we're at a point where I think it's a no-brainer to choose JS for just about any complex UI. The problem is you're wading into a fast-changing, diverse ecosystem, and a few wrong choices there can be very painful.

Re: Integrated Terminal Performance Improvements

#36

Post by simlevesque »

copperx wrote: post #34
altano wrote: post #18

Earlier quoted context omitted.

It doesn’t use canvas

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.

Re: Integrated Terminal Performance Improvements

#37

Post by [deleted] »

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…

[deleted]

Re: Integrated Terminal Performance Improvements

#38

Post by koolba »

batmansmk wrote: post #29
koolba wrote: post #23

> Misaligned characters: Due to many monospace fonts not being strictly monospace for some Unicode characters, this could lead to situations like the one seen on the right-side of the image below: (image) What are they referring to? I've been staring at the pic for nearly a minute and can't see anything misaligned.

Top right and bottom right corners of the green box.

Oh duh! I was staring at the text that I didn't even notice the borders. Thanks!

Re: Integrated Terminal Performance Improvements

#40

Post by WorldMaker »

revelation wrote: post #14

That is pretty concerning if they have to drop down to what is essentially a slightly improved framebuffer to get acceptable performance for a terminal emulator . The Electron waters are shallow and when you jump in head first you might hit a performance wall sooner than your feet hit the water. I predict that by 2020 they'll have migrated the editor and terminal emulator to an OpenGL surface.

Or maybe you just underestimate the demands of a terminal emulator? More specifically, the demands of many users of a terminal emulator. People want to try to see the matrix, they want 60fps scrolls full of arcane details too quick to actually be useful, but clear enough to kind of skim to give the impression that it may be useful.

VSCode isn't the first terminal emulator to use a videogame canvas renderer approach (by decades), and won't be the last. (Not just because the work was PRed to a shared library that other applications use too, but also because there will always be people trying to see the matrix in terminal emulators as long as there are terminals to emulate.)

Post reply on HN