|
| ▲ | gedbnfnc 9 minutes ago | parent | next [-] |
| This is a standard feature in every IDE that’s ever been invented. It’s not useful for every workflow, but there’s lots of times that you’re doing something where the console or the debugger is not available or isn’t convenient and being able to have a terminal right there is so useful. If it doesn’t make sense for your workflow, then don’t bring it up, but given how many developers expect us as table stakes it’s a deeply baffling omission. |
|
| ▲ | lynndotpy 3 hours ago | parent | prev | next [-] |
| I come from Linux land so I'm used to things being lightning fast, so using software on a Mac requires a thousand workarounds. A terminal integrated into the IDE is one of those necessary workarounds. MacOS has very very slow slow window- and desktop- switching (over one FULL second to switch from one desktop to another - this is not a joke!) so having a terminal integrated into the same application is very useful for maintaining flow for users developing on a single-screen Macbook. |
| |
| ▲ | spacedcowboy 2 hours ago | parent | next [-] | | I guess I’m not seeing what you’re seeing. I don’t often switch desktops - I tend to keep a project on a desktop, and there’s enough real-estate for everything I need for that project right there - and I don’t work on more than one project at a time. Window switching is instantaneous though, and I do that a lot | | |
| ▲ | lynndotpy 2 hours ago | parent [-] | | As you said, it's the set up. I'm almost exclusively using a single monitor, which works well when there's zero cost to switching desktops. For your use case, imagine if the Window switcher, instead of being instantaneous, was a ~1200ms animation which blocked all key presses during the animation. |
| |
| ▲ | Aloisius 2 hours ago | parent | prev [-] | | It shouldn't take over a second to switch desktops. I just checked with a screen recording. Switching desktops takes 15 frames (250 ms). If you turn reduce motion on, it takes 13 frames (216 ms). | | |
| ▲ | lynndotpy an hour ago | parent [-] | | The 1200ms was an estimation, but it's definitely closer to 1200ms than it is for 250ms for me. There's definitely a difference in set up here- I'm on a Macbook Pro with an M1 Pro chip. From a screen recording, I count 53 screen-recorded frames from the apparent start of the animation (which occurs after it's invoked) to desktop widgets becoming transparent (which appears to be the point input is no longer blocked). IINA says the video is 50.582 fps (very strange frame rate?) so that would be ~1050ms. Of course, that doesn't include any input latency or the display latency, so I also took a video with my phone. I took two trials and I recorded a full 1.08 seconds from key depression to transparent widgets. I did two more with Reduce Motion on and got the exact same time. I am very curious what your set up is, because I am invested in getting this as close to 8.3 ms as possible. edit: For comparison, my Linux desktop with a similar experimental set up, this takes about 24ms from key depression to the next desktop becoming visible. The only experimental difference is that I had to switch to the "slow mo" camera to record the difference, and I have a 240hz monitor. The desktop is also considered one of the slower ones (GNOME). TLDR: It takes 1.08 seconds, on my Macbook, to complete a desktop transition. |
|
|
|
| ▲ | rob 4 hours ago | parent | prev | next [-] |
| I use the built-in terminal "panel" inside VS Code/Cursor all the time. It's next to some other useful tab panels. Great for when you need to run commands for the current project but still want to chat in the sidebar or edit something else while it runs. Sometimes I'll use Ghostty at the same time and switch between the two. Just depends on what I'm trying to do at the moment. Nothing wrong with maintaining all the context you need in a single window instead of alt+tabbing to different apps, especially for those not engulfed by three 4K displays. |
|
| ▲ | 9dev 4 hours ago | parent | prev | next [-] |
| Because I like to get project-aware completions, or run pre-configured tools from the IDE in an actual shell, for example. Also, when working on multiple projects, it’s much easier to have shells attached to a specific project that I can toggle with a keyboard shortcut to get process output or Claude right next to the code I’m looking at. |
|
| ▲ | socalgal2 2 hours ago | parent | prev | next [-] |
| I used to use terminal windows separate from my editor. Now I use VSCode, I have 6 different but related projects open. In VSCode this means 6 windows, each with multiple tabs etc. In each of those are 1 to 3 terminal editor windows. That means when I switch to that project, shells related to that project come with it. No having to hunt through 6 to 18 terminal windows to find the correct one(s) Turns out, for me, the terminal emulator embedded in the IDE has been a big plus. |
|
| ▲ | zamadatix 4 hours ago | parent | prev | next [-] |
| I'll use both depending. Things which benefit from staying in the window context in the IDE window I use the IDE one, things which don't as much or are only tangentially related in an iTerm2/Terminal/Foot window (depending on the platform I'm on). I expect others do things differently for different reasons as much as much as I expect an IDE to support more than one type of user. |
|
| ▲ | timtimmy 4 hours ago | parent | prev | next [-] |
| Even with IDEs that have a terminal view, I still much prefer using a separate terminal app. |
|
| ▲ | DonHopkins 3 hours ago | parent | prev [-] |
| Ha ha! You sound like a vi users asking an emacs user why the hell you need a shell window in emacs! |
