Comment by 9dev
10 hours ago
First time I tried it, I realised there is no way to have a terminal emulator panel. A bloody terminal. Like the most basic feature you could integrate into an IDE. No thank you.
10 hours ago
First time I tried it, I realised there is no way to have a terminal emulator panel. A bloody terminal. Like the most basic feature you could integrate into an IDE. No thank you.
I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE. There's a perfectly good terminal emulator called Terminal.app, it's usually the first thing I put on my dock after a fresh install of MacOS. I like the terminal, but ... in an IDE ? I always wondered why Eclipse had one as well - it just seems like a wasted pane ?
Perhaps it's just the setup you (the generic "you") are used to or something. I've got 3 4k screens connected to a Mac Studio here, and plenty of space for a terminal or four to be running on-screen at the same time and in windows that don't obscure the things I want to look at. I guess if you code on an MBP and space is limited, it might be easier to switch to ? But I generally want that space for my debugger and console-app i/o. I think it'd just get in the way...
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.
> I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE
I assumed it came from Windows users who have a habit of running everything in full-screen.
I'm sitting here wondering why you'd run anything not full-screened, save for some rare situation where you are comparing multiple windows line by line (and don't have a short term memory).
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.
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.
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).
4 replies →
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
1 reply →
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.
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.
> This is a standard feature in every IDE that’s ever been invented.
You should be careful making such statements to an audience in which many have been around when IDEs were invented.
It's certainly a useful thing to have, and yes, these days many IDEs do have it. But Xcode itself is from the time long before that feature became the default. And, unfortunately, it is mostly still stuck there.
Bold take. This hasn't been my experience.
I’d like to argue for a case against having terminals inside an IDE:
when your IDE crashes (inevitably), you lose the entire console context and all running processes within it. There is also no way to detach the terminal from the IDE, say when the IDE needs to be updated (constantly).
IDE terminals also tend to be buggy.
> [an integrated terminal] is a standard feature in every IDE that’s ever been invented
I invite you to back up your claim by researching the following (as a starting point).
Visual Studio, Visual Studio Code, VSCodium, IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, CLion, GoLand, Rider, RubyMine, DataGrip, AppCode, RustRover, DataSpell, JetBrains Fleet, JetBrains Air, JetBrains MPS, Eclipse, NetBeans, Xcode, Android Studio, Sublime Text, Emacs, Spacemacs, Vim, Neovim, Theia, Code::Blocks, Dev-C++, Neil deGrasse Tyson’s Seemingly Limitless Trove of Knowledge, Turbo C++, Borland Delphi, RAD Studio, Lazarus, Qt Creator, KDevelop, Anjuta, GNOME Builder, MonoDevelop, SharpDevelop, BlueJ, Greenfoot, DrJava, Son of DrJava, Evil Bizarro Son of DrJava, jGRASP, Barely Beyond Your jGrasp, JDeveloper, JBuilder, JCreator, Aptana Studio, Komodo IDE, Komodo Edit, Geany, Light Table (may it rest in peace), Brackets, Zed, Cursor, Windsurf, Trae, Google Antigravity, Void, VoidedBowels, Kiro, Qoder, Cline, OpenCode, Spyder, IDLE, Thonny, Wing IDE, Eric, PyDev, PyScripter, Pyzo, Jupyter, RStudio, Zasper, MATLAB IDE, Scilab, Octave GUI, LabVIEW, Arduino IDE, PlatformIO, MPLAB X, Keil µVision, IAR Embedded Workbench, Atmel Studio, Other FPGA Tooling That No One Has Heard Of, Microchip Studio, Code Composer Studio, STM32CubeIDE, Segger Embedded Studio, AvalonStudio, ElectronIDE, Replit, Gitpod, GitHub Codespaces, AWS Cloud9, Google Cloud Shell Editor, Firebase Studio, Codenvy, Eclipse Che, CodeSandbox, StackBlitz, Glitch, If you have read this far, I am very impressed, Codeanywhere, CodeTasty, CodeTasty+, CodeTasty++, SourceLair, JSFiddle, CodePen, JDoodle, ShiftEdit, AppJet, PowerShell ISE, Embarcadero C++Builder, some IDE that I began coding 10 years ago but never finished, PureBasic IDE, GameMaker Studio, Unity, Unreal Editor, Godot, Redot Engine, Construct, RPG Maker, Defold, CryEngine, Roblox Studio, Stride, Open 3D Engine, HaxeDevelop, FlashDevelop, Leksah, Pharo, Squeak, DrRacket, LispWorks, Allegro CL, SLIME, some IDE invented inside some company you’ve never heard of, CIDER, Calva, Cursive, Smalltalk/X, Visual Works, IBM Rational Application Developer, IBM Rational Software Architect, SAP ABAP Workbench, Oracle SQL Developer, Toad, DBeaver, HeidiSQL, pgAdmin, SQL Server Management Studio, Xojo, LiveCode, HCL Domino Designer, Clarion, Progress OpenEdge, 4D, FileMaker, OutSystems, Mendix, Salesforce Developer Console, placeholder for some truly hideous Semantic Web monstrosity, Oracle APEX, Oracle Forms Builder, some random side project that Stephen Wolfram commissioned an intern to build, PowerBuilder, WinDev, PrimalScript, SlickEdit, UltraEdit, CodeLite, Source Insight, Pelles C, Open Watcom IDE, LiteIDE, Nova, BBEdit, TextMate (not everything in this list is actually an IDE, apparently), CotEditor, CodeWarrior, Turbo Pascal, Borland C++, Visual Age, Visual Cafe, Forte for Java, Sun ONE Studio, Zeus IDE, SciTE, Programmer’s Notepad, Ultimate++, Cevelop, Zinjai, JCppEdit, WeBuilder, Bluefish, CudaText, Kate, gedit, Notepad++, PSPad, EmEditor, Textadept, Leafpad, Graviton, Lite XL, Lapce, Helix, Micro, Cosmic IDE, Squircle IDE, CppDroid, Pydroid 3, Squiggle, SapphireSteel, Codelobster, CodeWright, The Reverend Thomas Bayes’s Glorious Probabilistic Workspace, CSPro, Adobe ColdFusion Builder, yikes that last one gives me nightmares, Adobe Flash Builder, Basic4ppc, BlackBox Component Builder, Bricx Command Center, CA-Telon, Maestro I, Absoft, ANTLR Studio, Apple Dylan, Stardraw, DbVisualizer, Mule IDE, v0, Coder, Data Display Debugger, Softbench, Visual Basic IDE, Dartmouth BASIC IDE, Athas, Fresh Editor, PlayCode, MyEclipse
(Thanks Claude, once again you have been more helpful than a human, which is more than a little concerning.)
I don’t know if all of these are real or qualify as IDE’s, but I hope I’ve made my point: it turns out using the word “every” is a broad and bold claim.
And please don’t simply backpedal and say that you meant “most” unless you’ve actually done the research.
Even with IDEs that have a terminal view, I still much prefer using a separate terminal app.
Same. Standalone terminals will always beat those built into other things in terms of being good at being a terminal. No need to pile more bloat onto an already bloated IDE/editor, and besides it feels kind of like those old combo TV+VCR units where neither the CRT tube nor the VHS player were great.
If I'd do anything to Xcode or Android Studio, it'd be to split more things out of them and make them excellent at their core tasks.
Why? It seems pretty pointless to keep hot memory of the context of every app and tab you have open as to recall what process and tab and window ties to what thing you were doing at what time, when it's effectively all one related workflow inside your Integrated* Development Environment. Do you just keep a separate dedicated tab in your terminal for actions you would only do against a single directory?
1 reply →
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.
Ha ha! You sound like a vi users asking an emacs user why the hell you need a shell window in emacs!
> I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE
This is the dumbest response anyone can ever have to being presented with the answer to their own question of "what's wrong".
Ok you don't think this is important but your customer (or whatever) just to told you it's important to them. Surprise surprise this is literally why xcode sucks (because Apple seeks to dictate instead of accommodating).
Oh you're why they add that. I just use a dedicated app. What's the benefit of putting it in the same window as the editor?
Replied on a sibling too, but:
> 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.
Window switching is bad enough on MacOS, especially if you have multiple projects open at the same time.
...were built-in Terminal emulators even particularly common before VS Code? I remember that being a major feature of VS Code early on.