[theonething]

I like working in terminals. An IDE will never run in the terminal. Vim with the plugins I like run in my terminal.

[pjmlp]

Showing the age, Borland IDEs for MS-DOS, as one data point among many other ones.

In fact, the whole TUI craziness of IT world fashion is getting back to what used to be daily business in the 1980's and early 1990's.

[lolinder]

Sincere question from someone who doesn't understand this: why do you like working in terminals?

[gloosx]

It's faster. There are all kinds of vim modes and shortcuts in IDEs, but only in terminal you can turn off your mouse completely and just use the keyboard. It's also faster than any GUI program in terms of responsiveness, everything happens in an instant, and there is not a single animation, even when working with a 1GiB log-file. Vim is also a very robust tiling manager, convenient splits and navigation between windows, terminals and editing buffers out of the box.

[bionsystem]

Not the op but I like it too and here is why :

- I like awk grep sed find and many more... and piping things together

- I like the low latency of vim and love walking through code with just a few movers

- I like the ubiquity of using the same tools on any machine, local or remote (including windows now that it has wsl) and bash

All of this even more so than "no mouse setup" or anything, I don't mind using the mouse sometimes.

[camgunz]

I find that terminal apps are a lot more respectful of my machine's resources and whatever workflow I want to build. I can make them work like I want to. GUI apps make me work the way they want to, which as an incorrigible non-conformist is a real fly in the ointment.

[maxbond]

A programming language is a good abstraction for interacting with the computer. It's a metaphor for how a computer works. Graphical tools usually provide metaphors for how a certain set of tasks are done. The terminal is a REPL for a programming language designed for this purpose.

Simple command line tools become primitives in this language, and they compose together. Learn a few dozen and you have something quite powerful. You can remain in the same mental model to accomplish many tasks. Graphical tools tend to be monoliths that rarely compose, each premised off of a different mental model. This creates friction when moving from one to another.

For better and for worse, the terminal looks pretty much the same now as it did 30 years ago. (There are important improvements in zsh and fish.) Graphical tools tend to evolve quickly. If I don't use a command for 5 years, I can get back up to speed in a few minutes using it's built-in documentation (`--help`). If I don't use a graphical tool for 5 years, I'm pretty close to square one, and need to spend some time with the manual (in a separate application, the browser or PDF reader).

If something is missing from your toolkit, throwing together a proof of concept level CLI is pretty easy. Presumably some people can throw GUIs together very quickly as well. But the CLI is a simpler programming model. (Immediate mode GUIs do narrow this gap, however.)

And now your new CLI can integrate with all your other CLIs out of the box. Eg, a tool that tweaks some values in a JSON file can be used with the `find` command to tweak many JSON files.

(Your mileage may vary. I'm just trying to present a distilled intuition, if I seem to be speaking in absolutes, it's figurative. Whatever workflow works for you is the right one.)

[lolinder]

I guess I should have been more specific: I get all that about CLIs, but that doesn't really explain wanting your editor to run in the terminal. I usually have an IDE open alongside a bunch of terminal windows. What am I losing by not also running my editor in a terminal?

[maxbond]

You're probably not losing out on anything if that's comfortable for you. The primary advantage to me is avoiding context switching between a GUI and terminal mental model. But that probably just doesn't bother you.