Is it still possible to live in a terminal?

The Vim/Neovim ecosystem has gotten unbelievably better over the last 5-10 years. "Living in the terminal" for core development work is IMO better than pretty much anything else out there; my Neovim setup has a modern plugin manager; an IDE-like experience with fast autocompletion as I type, goto definition, and automated refactor support; and a side-drawer file browser navigable with Vim motions. It feels like an IDE, except that it launches in ~100ms and has ultra-low typing latency. Using it with tmux panes means I can have various drawers and panes with a series of full, incredibly fast terminals wherever I want, with long-running tasks like automated test watching/running while I edit code placed wherever I want around the editor panel. Not to mention the Cambrian explosion of "modern" terminal tooling getting built, like xplr [1], hyperfine [2], httpie [3], etc.

That being said, I think "living in the terminal" for general purpose computing, like browsing the web or talking to your coworkers, has been in a kind of frozen standstill while the rest of the world has moved on. I think it isn't worth trying to push non-dev work into the terminal currently.

1: https://github.com/sayanarijit/xplr

2: https://github.com/sharkdp/hyperfine

3: https://github.com/httpie/httpie

The answer is yes, but you have to make friends with the employees and plan to marry a local.

See this documentary: https://www.imdb.com/title/tt0362227/?ref_=fn_al_tt_1

I don't know about "living" in a terminal, but CLI/terminal tools are quite far from being out of the picture; if anything, I'd say they're thriving. It's not about one or the other; they're complementary, and I use both every day.

Personally, I use Firefox for browsing, PyCharm for coding, mpv/qimgv for media, and do pretty much everything else in the terminal. Terminal tools are incredibly versatile and composable in a way GUIs really can't match - for instance, I built a script that gets all the RAW files from my camera, converts them to jpg with darktable-cli, and optimizes them for filesize maintaining the same visual quality with jpeg-recompress, great for when I don't particularly care about editing each picture of a long hike. Next step will be to also push them to Google Drive, but I haven't gotten around to that yet. Similarly, the gopro-like camera I use for recording racing footage produces files with some weird filenames and terrible encoding which makes them enormous, so another script pulls the files, renames them to the date/time taken, and uses ffmpeg to transcode them to hevc, which saves several GB. Could I do this all from GUIs? Probably, but it'd involve a lot of hunting for files, dragging/dropping, and context switching between different programs. It's a lot more convenient to do it all in one short command.

There's also some amazing tools which just don't make much sense or would be quite contrived in GUI form. fd and fclones come to mind. AI is starting to be packaged as CLI tools, and it'll open up even more possibilities. Separate hiking pictures into their own directory? Sure! Find lecture videos mentioning a specific subject? No problem, this one doesn't mention the specific keyword you were looking for but it's also relevant at X timestamp!

I keep a 'perfect terminal' in the office, basically a system with an nvidia 7600 in it because that's the fastest 2D text thing I've found to date (yes, modern cards are so slow in text mode it's not even funny). Configured for 24 VT's, a bunch of them autoconnect to remote systems/run specific applications etc at boot - so if I want the calculator, for example, it's Alt-F12.

For local graphics programs, that also provides a memory-mapped framebuffer which makes basic graphics a doddle. Beyond that, text-mode browsing has been too hard work for years (and so by extension email too). While it's very possible to 'cheat' by setting X to render to a framebuffer (either directly or in the background) the whole reason to use the text-only console is to focus on code without computer-borne interruptions.

Even on my graphical computer, it's basically terminals windows and a browser. Any piece of software that interrupts the flow is either configured to not do so, or discarded PDQ.

Terminals FTW.

> - My company uses Slack's enterprise auth, and all the CLI slack clients I could find haven't been updated in years and no longer work.

https://github.com/wee-slack/wee-slack is decent.

> - The web is using more javascript than in the past.

cli browsers are probably the only truly unrealistic thing. An idea that I've been kicking around for a while is to build a simple CLI "browser" that uses PhantomJS or similar under the hood to request, load, and render the page into an image, convert the image to sixel (https://en.wikipedia.org/wiki/Sixel) and display it that way (or use any of the various terminal emulator-specific features (KiTTY has https://sw.kovidgoyal.net/kitty/graphics-protocol/ for example)). Probably pretty clunky, but it's doable if you're in the mood to write something purely for fun.

> - Mutt doesn't handle multiple email accounts natively for work/personal. The solutions are hacks at best. Email servers are starting to use more complete auth mechanisms that don't work well with mutt.

I don't think they're hacks. You can define exactly how you want it to work. That's a feature, not a bug. Sure, it takes a little bit of work to set up but you can use https://github.com/cweagans/dotfiles/tree/master/.config/mut... as a starting point if you'd like.

I do almost everything in terminal windows, but for emails, Slack, video calls, and other support-related things I use native MacOS/iPadOS apps. It doesn't make sense to do everything in a terminal because not every useful service works in a terminal. Choose your environment and tools based on utility.

Emacs (which can be run in the terminal using the "-nw" option) has a slack package -- I dipped my toes in and noped out quickly, as I found it too difficult and too ugly compared to using the app: https://github.com/yuya373/emacs-slack

I've tried to do the same thing: going completely text mode. For me, it was disastrous -- it was a big distraction for me at work, at two jobs. I even left a good job partially so that I could try to go text-mode rather than click my way through lots of GUIs. It was something of an obsession. Now I look back and sigh.

From the headline, I thought the post would have been about this guy: https://en.wikipedia.org/wiki/Mehran_Karimi_Nasseri

It is possible but inadvisable. A more realistic approach would be terminal + browser.

Living in a terminal itself doesn't really mean much, as it strongly depends on your tasks. For things like number crunching or programming, it has a pretty big benefit (as text is the universal API after all), and you can do pretty much everything, usually faster and more reliable than a GUI can.

But when you need to do data visualisation, make use of external services that do not provide terminal emulation interfaces or want to work with people that do not live in a terminal, that makes a 60/40 split the best choice.

Early on in my "Linux journey" Xorg and KDE both made some drastic (and not well planned) changes simultaneously that left me stranded in a terminal for several weeks. During that time I was surprised to learn how genuinely functional and capable the terminal could be. Turned out that nearly everything I needed to do was still possible with very few exceptions. Much of that still holds true today, with one major difference. The tools we have at the terminal these days are much nicer than they used to be. Some of them are quite close to GUI tools in their functionality and richness of display output. Because of this I still use the terminal quite heavily even while working primarily in a GUI environment, just because for many tasks it's quicker and easier by far than hunting through a GUI looking for the right place to click to get a thing done.

The solution is not to get religiously terminal.

I keep two desktops open and can flip with a keystroke.

One of those always runs a full screen browser on gnome desk, and the other is the shell.

I flip between those. Email is webmail but on the other screen code editor is vim.

Since Emacs runs just fine in a terminal, I imagine so.

Although, if you are going to live in Emacs there might be enough terminal there without actually running it in a terminal.

> - Mutt doesn't handle multiple email accounts natively for work/personal. The solutions are hacks at best.

I don't know about Mutt, but I've had no problems handling multiple accounts with mu4e on Emacs. `emacs`/`emacsclient` can be forced to use the terminal by using the `-nw` option.

isync/`mbsync` can also work with multiple accounts. Although, this program just sync's an IMAP account with a local Maildir that clients like mu4e can use for reading mail offline. It's an MRA[1] rather than a whole MUA.

There are many other terminal email clients you can also try.

> Email servers are starting to use more complete auth mechanisms that don't work well with mutt.

Google can support standard auth by activating 2FA, then making an app password. You can do this here:

https://myaccount.google.com/security

Google specifically needs "more complete auth mechanisms" because its regular password gives access to much more than an email account, since Google accounts are a huge platform. What other servers are moving away from standard auth mechanisms?

[1] https://en.wikipedia.org/wiki/Mail_retrieval_agent

I was a terminal poweruser wannabe. For a time I tried just using tmux and Vim on almost all occasions. I still use Vim for something, like writing Puppet code. For everything else: I've just come to embrace to the GUI.

Unless you're an absolute terminal power user that can masterfully navigate tmux, vim or whatever tools you use, I don't think it's a good use of time. There certainly are things where the terminal is the right tools, use it in those situations. Just ask yourself if you're artificially limiting yourself, simply because you think the cool kids use the terminal.

Many of our latest hires (new college grads) struggle with terminals and CLI in general. It seems like recently students have stopped getting this exposure which leads to them joining and not knowing how to ssh into a damn linux VM. It's a pretty daunting world.

For Slack in particular, the deal is that new signins return a token that starts with "xoxc", not a token that starts with "xoxs", and that token requires corresponding cookies in order to be accepted. If you're grabbing a token out of the browser, you will also need to get cookies for slack.com and pass them in the client. Last I checked, you only strictly needed the cookie called "d", but you may as well grab all of them.

A bunch of folks who have been using Slack for a long time have saved their xoxs cookie from a couple of years ago and not invalidated their old sessions, and they'll tell you the various clients still work. For a new user who is getting an xoxc token, your client needs a way to pass cookies along with your token. Many of the terminal clients I've seen don't obviously give you a way to pass the cookie.

My company uses the enterprisiest Slack offering (Enterprise Grid, compliance archiving, proxy restrictions, the works) hooked up to Azure AD as the identity provider and previously to Okta via ADFS, and I have working programmatic auth to Slack (leveraging local Kerberos tickets from Windows AD signon). Give me some details on what your auth setup looks like and I can probably help you with it. (I can try to open-source my internal client if it helps, but it's specific in some ways to our setup so it might be easier to just talk you through it.)

I still find it utterly baffling that Windows and Apple haven’t integrated better “hyper-productivity” oriented workflows into their OSes. I’ve tried (and failed) on multiple occasions to “ditch the mouse” for full keyboard nav but it always comes up short around the browser. Even VS Code has pitiful keyboard-only navigation support.

These days I pretty much work exclusively in terminal, having gotten used to vim mappings and just sticking with it. Still, I’d rather be on a desktop.

It obviously depends on your working environment..? I'd be screwed 5 minutes into my workday having to sign into our PDM.

> It seems like the terminal world is slowly getting abandoned in favor of proprietary GUI apps.

Eh, I'm seeing quite the opposite trend. I see people doing stuff that'd consider using a terminal to be straight up inappropriate for (e.g. displaying line graphs).

And your troubles with Slack is most likely down to it being proprietary garbage.

For everything except web browsing, I use the terminal.

neovim - text editor

aerc - email

nzbget - usenet

irssi - chat

mpv - audio

still hoping for gemini to take over for a full terminal experience.

I'm not sure what specific issues you've had with mutt, but I have mine setup with multiple accounts & have in the past used it for a work account where I had to do IMAP/SMTP auth via oauth token rather than username/password. It's definitely not a super well supported happy path & requires some setup, but it's worked well for me.

- Multiple accounts: I have a per-account config file with the relevant specifics (https://github.com/wfleming/dotfiles/tree/arch-linux/home/co...) and use folder hooks to apply those depending on which mailbox I'm viewing (https://github.com/wfleming/dotfiles/blob/arch-linux/home/co...). (Plus a keybinding in each account file to make flipping to the next account easy.)

- Non-standard auth:

  - I use offlineimap to sync my mail, and it supports oauth2 for Gmail. The arch wiki has helpful details: https://wiki.archlinux.org/title/OfflineIMAP#Configuring_OAuth2_and_getting_access_tokens_via_mailctl

  - For sending mail, I use msmtp, which also supports oauth2. Again, arch wiki has some helpful details. https://wiki.archlinux.org/title/Msmtp#OAuth2_Setup

For web & Slack, I sympathize and have toyed with CLI alternatives in the past, but I'm come to terms with the the fact that it's just not that feasible for the most part. Personally, I spend as much time in the terminal as I can, but I've given up on fighting against the tide for everything. The only native apps I usually have open are Firefox, Slack, and Spotify, and that's acceptable to me since it ends up meaning I still spend most of my day in a terminal.

Terminal code review seems to be a niche looking for an occupier. I live in my terminal for editing text and code, running code to generate more text (test output), deciding how to break that code into meaningful chunks and writing about what each chunk does to make the codebase better (git).

This is realistically a huge part of my job.

The next part of the cycle though is always web based. Where are the code review tools that integrate with my editor? Why am I not reviewing someone’s changes presented as a branch in my working copy? Can I do this without having to make the cognitive break of leaving my development environment and moving to a web page facsimile — albeit a very good one — of the place I do my own thinking? Being able to make suggestions by editing the actual code (and testing it) would be huge.

A solution to this would be amazing.

Does GUI Emacs count as sufficiently terminal-ish? You can embed a Webkit-driven browser into Emacs, and then do anything browser-y you need to from there: https://github.com/akirakyle/emacs-webkit

I lived without X11/Wayland for several years. (These days, I live in GUI Emacs with EXWM instead, which has a similar feeling.)

Some tools I had luck with:

- mpv is your friend - it can play audio, video, and display images directly to the framebuffer without X11. It also makes a pretty decent PDF reader combined with ghostscript to render each page to a PNG.

- The Emacs ecosystem is very useful - there are many packages for interacting with common services, and they typically work in both terminal and GUI modes.

- For web stuff, the best solution I found was to push as much as possible into RSS feeds and/or IRC, which have good terminal clients. Things like rss-bridge and bitlbee are great here. When I needed a browser, I typically used Elinks but was never really satisfied with it. I believe if you need decent JS support you're out of luck.

One of the upsides of the pervasive JS is that it often calls APIs that do useful things. If you take the time to capture and study those interactions, you can develop your own libraries and CLI tools that operate those useful APIs, too [0]. Then, you can think of "browser time" as an investment that begets more "terminal time." Also, if you stick with simple interfaces for your CLIs (e.g., read and write pretty printed JSON instead of inventing your own "human readable" formats), it's much easier to make your tools snap together like German nouns, like McIlroy intended [1].

[0] This is all subject to how much you care, of course. Not all automation is worth the hassle.

[1] His metaphor was actually garden hoses that screw together.

When I saw this subject I thought it was about living in an airport terminal, like Mehran Karimi Nasseri did in Paris for 18 years.

https://allthatsinteresting.com/mehran-karimi-nasseri

the web is what keeps me in GUI land, and Browsh (https://www.brow.sh/) isn't quite good enough to make do with.

There is a pretty well updated cli for Slack built on top of WeeChat (hailing from IRC heritage) https://github.com/wee-slack/wee-slack

I couldn't disagree more with the premise of this post. I've never been more productive at the terminal in 30 years. The thrust of your complaints appear to be you can't do company IM easily at terminal, but given most employees will want strong audio/video conferencing features too this is perhaps not all that surprising. We have whole classes of new CLI tools that didn't even exist 20 years ago today, allowing us to trivially launch complex application stacks in a few lines.

I think the effect of javascript's wide deployment on terminal tooling is very marginal at best too.

I wonder if you included a JS REPL/console in your terminal if you'd hit an interesting enough hybrid.

Something like Puppeteer/Playwright where you can spin up headless Chrome instances from the terminal, interact with them and automate them in JS. Treat the JS as a mini shell script language in your terminal of choice.

I'm almost surprised there isn't yet a terminal that is an intentional JS-hybrid where you can REPL JS and/or directly shell script in it (beyond just Node scripts).

Probably not entirely worth the time to build such Rube Goldberg contraptions, but an interesting thought experiment at least.

As long as coding stuff can be done through SSH, TMUX, VIM and terminal I'm fine. I've got a netbook-like tablet(s3 active with keyboard cover) and working on it is real nice(I hope to start going a bit more nomad soon), I have to switch apps to Slack & browser but the OS handles this so why bother.. My 2013 notebook also holding up well since what I need besides the term is just the browser... I don't think it's going away, but for this kinda of port to be maintained it needs to fit in with what workflow the termnerds and geeklords are doing, I guess.

In my mind I like to entertain the thought though that this bare way of working computers is discovered by more people & younger generations, that maybe they pick it up and do more cool stuff etc because it's something I only grow to like more and more over time. Btw I was never was like the hardcore linux wizard or anything, more like 'touch typing + this is kinda like playing a fighter'. I've got 2 trainees who are trying to pick up Vim right now and I guess a lot of ppl notice it since they never saw someone coding like I do, like doing typing combos and working mostly at the CLI. It's also funny because my colleague at the company is a very respectable senior and about my age but its 2 totally different styles, he's using vscode & autopilot.

I have some RSI though and it sucks when it starts popping, nowadays that mostly when Im working more remotely since then I use normal keyboard & key setup. On my work computer I have a typematrix with some key customizations that have helped A LOT.

I wonder whether anybody has developed a CLI browser that also has a JavaScript engine. I've seen plenty of TUIs that have modals, text line inputs, etc. You could probably get pretty far so that at least you can support more of the Web. At least to start with just using an engine to allow JavaScript to have control over HTML elements would be a start that would solve many of the issues with text browsers.

I was doing this experiment few years back with `emacs -nw`, tons of other packages in Emacs and custom elisp code. Used `ein` in emacs instead of Jupyter notebooks, browsed web in text browser etc.

But as I grew older I realised I need to pick my battles wisely. I still use emacs for some simple edit tasks and tramp for remote server file edits. But for normal day to day development that pays the bills, I've switched to vscode.

GUI based apps are offering better experience. For example, I can still configure Emacs to work well with Golang or Python. But the out of the box setup you get by clicking couple of buttons in VSCode is far superior.

It is separate matter if terminal world is getting abandoned is right thing or not. Maybe it is relic of a different era: when computers were time shared machines and connecting to them with terminal was the only option. But I increasingly realised that isolating myself out of better GUI based options is not the right battle to pick.

Question for OP: why do you like terminals/CLI applications? What are your needs?

For me, CLI applications are nice because of their ability to interface with others with things like arguments, stdout etc. Dumb and simple to string together a series of applications that feed into each other to give you what you want.

Desktop apps don't focus on that or if inclined would set up rigid interfaces that require communication over IP (read: expensive and inflexible)

Mobile apps grew into this and so will VR/AR/XR.

My call to action would be to encourage you to develop smaller, useful components that others can run to string together their own experiences/solutions.

In mobile apps, this would be providing more integrations to IFTTT or iOS's shortcuts.

My use cases would be to dump information out of apps and grep them. Just give me a damn file I can grep!

It's still possible to live in the terminal, but only in the same way that it's still possible to eat healthy, but you'll have to identify and eliminate all the junkfood out of your life first, and your current junkfood-loving friends may not be able to remain your friends for too long after this kind of lifestyle change.

Having said that, I often wonder the reverse. I'm so happy with my terminal, that every now and then I wonder how much longer will it be possible for me to put up with all the junkfood-equivalent crap that is forced down my throat on a daily basis before I say "enough is enough" and go into virtual hermit mode?

Are your concerns about the lack of open APIs or the lack of command line apps per-se?

Personally I'm all in favor of having more open APIs and third party clients, but would never want to intentionally constrain myself to a TTY that is half a century old.

Yes, but it depends a bit on the exact nature of your job. At the last job, my Linux work machine never had a mouse plugged into it because I never needed one. The macbook the company gave me was the "chat/email machine".

Nowadays, I have to run a proprietary VPN client that only works via GUI, but even though a full screen terminal emulator isn't as "pure", it feels the same.

I love it: absolutely zero distractions, it's a huge productivity win for me. But I realize I'm lucky in that the kind of work I do doesn't require me to be responsive to chats and emails (my reply latency is 24h).

Another alternative solution for Slack is to use Beeper (https://beeper.com) or just run the Slack bridge they use yourself directly (https://gitlab.com/beeper/mx-puppet-monorepo/-/tree/main/pac...) to bridge Slack into Matrix. From there you can use any CLI-based Matrix client you like; weechat, gomuks, whatever.

About browsing, I had difficulties with Lynx as you can't use tabs. The last versions of Elinks were broken on OS X and outdated. I found a fork of elinks (Felinks) that offers everything I want and is easy to configure.

https://slackbuilds.org/repository/14.2/network/felinks/

https://github.com/rkd77/elinks

I'm a very terminal heavy Engineering Manager and Technical Lead at a ~600 employees tech startup.

Slack is a tricky one and there are no decent terminal clients available, but I do a LOT of e-mail on mutt as my main client and could not be happier and write all my code in vim. I don't think you can "live" on the terminal, but you can still realistically use it to power a significant part of your work.

I second the need for a good Slack terminal client, or at least a service to proxy Slack to IRC or something like that. The Slack app is super slow.

I do most of my work in the terminal. I work on JavaScript/TypeScript projects. Soon Java, we'll see if I use the terminal for that.

I love streamlining my ZSHell and ViM experiences by tooling around and have produced some nice scripts and functions which are both living documentation and useful to share.

However, I wouldn't expect my team to maintain shell scripts as they're a bit esoteric.

I quickly navigate around and search my files, use version control, switch projects, run services, and open sites in my browser using terminal and Vim commands.

I have to switch away for debugging though.

Depends on environment. At work we have official corp communication platform - Teams. Most UI build for browsers and require a lot of complex JavaScript for render.

But most of my work is still done in terminal. Most project I managed ended up with very nice CLI applications, makes things a lot easier in the end, like automations for example. Initially specially younger engineers struggled with decision to build cli instead of web portals. But later realized how effective and productive the decision was..

I think the error is in your thinking of where the problem is. If you use screen or tmux inside a terminal what you are doing is relying on a window manager. If you are not using a terminal multiplexer and living in a single terminal you are just unproductive. Look for a window manager that fits your needs and graphical/ textual web browsers are no longer a defining limitation.

That said, there are a lot of people who have gotten off track on this including both the teams developing web browsers and those developing terminals.

I still use the command line extensively. However, I use a browser for collaboration tools and email, and Emacs GUI for coding. On the work computer, sadly a Windows box, I have no such luck.

Having said that, current windowed terminals are a sad shadow of the days of the VT330. Almost none can do double-width and double-height, many can’t blink, and none can do smooth scrolling.

Honorable mention to Apple’s (NeXT’s?) Terminal app, that can, at least, do double width and height.

None has Tektronix or ReGIS support - which would be wonderful for graphic panel applications.

I go for a terminal-first approach. If a CLI exists for what I want to do, I'll try it out.

If a GUI would be easier, I use that. If there is no CLI, I use a GUI.

At least for me, browsing the web, email, creating professional documents and developing large software projects mostly happen in GUIs. There are related tasks that are easy to shell out to, though, so it's not like I'm sticking to GUIs for everything.

I was never a fan of chatting using the terminal, so I use GUIs for that.

You can, if you’re working as an independent consultant. I have a few friends like this who do live in a terminal. (I am also a consultant, but Gnome works fine for me)

> It seems like the terminal world is slowly getting abandoned in favor of proprietary GUI apps. > Anyone still living inside the terminal? Links to tools for Slack are appreciated.

Fortunately, I work for a company that does'nt use slack or proprietary apps. I've been thinking of some kinda proxy for text browsers with customizable .. edits, to hide excessive html elements form the terminal. (Might need to be per site ?)

Sure! You can also use a Model T for all your auto needs.

I stopped using emacs to manage my mail in 1996 when my colleagues started to send me Word and Excel attachments. Not only I was using a text only client, I was using it on a Unix OS.

I moved my mail to the predecessor of Exchange on a Windows 95 PC. I went on for years with MS Express(?) and Netscape / Thunderbird for my personal email and Exchange for work email. Then only Thunderbird since I went self employed.

This is a question about lifestyle, really. Most "ways of living" that deal with modern office environments can't do it. And a lot of bureaucratic functions need a graphical browser.

But if your day to day is physical labor, crafts, writing, theoretical research etc. - you don't need the computer much to begin with.

If you allow your phone to act as your sole graphical environment, I think it can work out.

I use only terminal programs for my development job. There has to be a real good reason for me to use a gui while working. One such good reason is a web browser. there is simply no way to work in the modern world without one. (for a large percentage of people anyway)

git, vim and plugins/addons for it, *nix tools in general, man pages etc. don't need more than that and a browser.

The terminal is still the most efficient control center for the machine. We have less control than before so we get dragged into the cloud, onto centrally coordinated networks.

There are converging factors that will give back some control but I think people should be treating that convergence with more urgency than we do now.

Of course the terminal should also evolve, new standards need to be set.

I do most of the work in the command shell, and in other programs in the terminal emulator (IRC, email, NNTP, and some games). One which isn't is the web browser, although I do not use it for everything. (Sometimes I do use Lynx, though) In some cases I had written programs if needed.

Sure it's possible to live in a terminal, assuming you're willing to impose shit like this not just on yourself but upon everyone you interact with: https://stallman.org/stallman-computing.html#internetuse

dude, I've been reading posts like this since the nineties (on Slashdot.)

Terminals have been 'going away' for longer than I've been alive, and they will continue to diminish long after I'm gone.

The reason they don't ever get there is that the market as a whole is still increasing in size overall, even as the stock of TUI-natives dwindles. There are simply so many more people working on e.g. neovim, kakaoune, and himalaya (an email client) that the fact that there are even _more_ more people using GUIs simply doesn't matter as much.

Put another way: the increase in absolute numbers of TUI/CLI users is the statistic to watch, not the relative percentage of users.

Finally, terminal chops are a nerd status symbol -- a form of conspicuous consumption of time and muscle memory. Humans tend to drop status symbols _last_.

I don't brag about my use of VSCode, but I sure talk up my neovim config in interviews ;D

For email, it appears Alpine (the successor to Pine) supports multiple email accounts via Roles. I have not tried this.

Maybe you'll find something you like looking into a matrix slack bridge alongside a command line matrix client

>- Mutt doesn't handle multiple email accounts natively for work/personal. The solutions are hacks at best. Email servers are starting to use more complete auth mechanisms that don't work well with mutt.

How come? I use hundreds of email accounts with mutt and have never had to do any special configuration.

When I was reading the headline I thought of people like this: https://www.airport-technology.com/analysis/terminal-dweller...

> Mutt doesn't handle multiple email accounts natively for work/personal

My solution for this is to simply run mutt twice, with different .muttrc files and in separate tmux windows.

I prefer this, I don't want personal and work mail (or notifications) mixed together.

This is like asking can I fix my car with only a set of wrench and a few tools. The answer is yes but it will be hard in situations. One is trying to do anything graphical unless you are launching a gui app from terminal, but still call it “inside”

I tried it in the past and it worked quite well, except for Slack: I got it working, but it wasn't great.

For email, I can suggest aerc [1]: lovely piece of software!

1: https://aerc-mail.org

Yes unless you work with language that "needs" an IDE like java, scala ect.

> It seems like the terminal world is slowly getting abandoned in favor of proprietary GUI apps

This sounds like something written from the 1990s.

In fact these days, proprietary GUI apps are being abandoned for web apps or mobile apps.

It’s more possible today than ever.

There’s more commitment to it today than ever.

There’s more command line mtools than ever.

It’s not about one solution of CLI only or some east front end. Both have their place as beginners become experts, and beyond.

Slack used to have XMPP integration, so you could have used https://profanity-im.github.io/ for chat.

> - My company uses Slack's enterprise auth, and all the CLI slack clients I could find haven't been updated in years and no longer work.

weeslack works fine

Is it ”possible”? That just depends on what you are willing to give up. You clearly aren’t fond of video calls if you consider giving up a graphical desktop.

for mutt, I use Luke Smith's mutt-wizard and can do several accounts, I switch accounts with `i1`, `i2`, etc. for the different accounts, though I'm not sure if that fits your use case

for the question I'd say "depends on what you want to do", if you have to interact with people who use slack, then probably no, unless you make your own CLI client to it, same with the web

No, you cannot. Assuming you are human; you require air, water and food to live. The terminal does not provide any of these.

Now I am coding mostly in vi, in the VSCode Terminal, in the Docker contains, in chrome browser.

Here I am thinking about Tom Hanks.

If you're willing to compromise by also having a modern browser, absolutely.

I really just enjoy using i3wm tiling window management for terminal multitasking.

> Links to tools for Slack are appreciated.

I would tend to think most of these suck. Slack is a proprietary chat app. Why would people contribute significant free time to make something for it?

yes except for the browser, you can use weechat it's a cli irc client but you can link a lot of accunts (slack, fb messenger, etc.)

no, but a terminal and a browser is a good compromise between terminal only and going full enterprise office software mode.

Even my local library stopped using terminals with monochrome screens and some database system written in COBOL. Now they have webbrowsers.

Perhaps it is time to upgrade :)

How do you read documentation for work?

there's also a resurgence of lean fast TUI, fzf, bat, neovim, python libs like textual

Can’t use Zoom inside a terminal.

No, you need food and water.

80% is good enough for me

Nope, I live in a house.

Until few years ago I was a hard-code unixer, witch means zsh+Vim, even if on X11, on modern terminal emulators like Terminator, Tilix etc. Then I've decided to seriously do a thing I've only superficially and never really studied before, after seeing it in action: try Emacs seriously.

In a little time EXWM have replaced my WM, Emacs have integrated a big slice of my previously favorite tools. It's not perfect, it have bugs/flaws, but is so much powerful than the Unix model and the modern GUI model(s) that outshine anything else. I still use zsh, eshell it's a bit too limited/alien to me so far, unix tools lacking a LispM underneath are still serving me under the wood but that's is.

Said that, as you rightly state the actual IT model, VERY unfortunately for the humanity at a whole and no, I'm really serious, have shifted long ago to classic desktop model toward a modern limited and limiting model and now even worse to the old mainframe+dumb terminals model, where the mainframe is external, someone else computer, the cloud and dumb terminals are now "endpoint", utterly complicated pile of crap to boot up a WebVM improperly named browser for legacy reasons. In the actual state of things choice is limited: some "services" can be integrated more or less easily, more or less stably/reliably, others can not.

That's why I've first shared my person journey toward Emacs: even if sit on top of Unix, like a bootloader, not much differently than the aforementioned WebVMs it can wrap Unix and integrate X11/WebVMs (cr)apps a little bit. Doing so does not totally solve your issues, BUT solve partially many of them and gives you something FAR more powerful/evolved than Unix. You can't do much more than that.

To use a truce metaphor: we live in a dramatically lost war, chances to win before dying are utopia at best, but at least we can live the unique life we got a bit armed instead of being totally at the mercy of every enemy. Your car if not today, tomorrow will demand you a login on a smartphone to a cloud service just to open the door, so your WC to lift the cover, your country will demand a smartphone just to pay taxes in an integrated cloud-mobile platform no one really know who really control at a certain "zoom" level, no one can really do anything outside it but you can so far still have a small personal garden that ease your life a bit at least giving a comfortable environment with your data locally available so much powerful that can help cope with the outside world crap.

BTW Slack, a CRAPPY service no damn company should be so crazy to choose it, is supported by some Emacs packages see for instance https://www.emacswiki.org/emacs/Slack as usual it's not a full and bug free support, but you can use it, like you can use Jira etc.

weechat + bitlbee

It doesn't work for business at all because if you want to do business you have to meet people where they are. You can't email a client and say, sorry, can you please send me that contract in a text file, I only have a terminal. Or, sorry, I can't use your web portal to access the data because it uses JavaScript.

If you're not doing business, using the terminal works fine. Up until you have to deal with health insurance or your power bill or your taxes or bank.

Unfortunately the world now revolves around [gui] web browsers. We brought this technologically retarded hellscape on ourselves and we deserve it.

If companies choose to use proprietary software for needs that FOSS can and has served well for years, it would seem that those companies are cutting their own legs.

I speak primarily of Slack and Zoom and other “low hanging fruit” of already solved problems that feature VC-funded wheel reinvention made popular by their VC-brethren dogfooding said products, when threaded messaging and webRTC don’t necessitate proprietary solutions. https://meet.jit.si for example…

I don’t think mindless cargo culture is a trend to follow, nor will tech savvy devs disappear nor will the need to remotely administer servers via command lines tools disappear.

Remote Desktop solutions are not realistic tools for server administration in any sort of serious way, so I’m pretty sure that’s a niche that will always exist…

Seeking to browse the web exclusively through a cli browser, however, is probably not something one can do while working in the field of web development. The web is primarily graphic lauout based