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

It looks promising at first with LSP and all that but I don't know when I had any stable moments.

I'm guessing the few dozens of plugins are probably messed up in a way or another after each updates.

Apparently, there's no unified QA testing among community supported ecosystem with 20 different authors.

- For a plug-in manager I user packer

- For file/text search I recommend telescope (https://github.com/nvim-telescope/telescope.nvim)

- Copilot (https://github.com/github/copilot.vim)

- Nerd tree for file browsing (https://github.com/preservim/nerdtree)

- commentary for commenting (https://github.com/tpope/vim-commentary)

- ALE for linting (https://github.com/dense-analysis/ale)

- Mason for installing LSP servers (https://github.com/williamboman/mason.nvim)

Once you have the proper tooling in place you can do pretty much everything in vim that you are doing in vs code or intelliJ. I've just started using it for most of my dev work recently and I have found ThePrimeagen's youtube videos on vim to be a great resource.

Series on using vim as you editor (https://www.youtube.com/playlist?list=PLm323Lc7iSW_wuxqmKx_x...)

Introduction to setting up your vim configuration (https://www.youtube.com/watch?v=x2QJYq4IX6M&t=512s)

I recommend giving it a try. The process of learning it all was fun, and as you may have heard you can eventually get pretty quick using Vim.

I haven't found any other tools that does simple things like extracting a function, renaming or inlining variables. For example, vscode's Python support is terrible.

For example, I had a VSCode coworker who was asking to switch all typescript string union types to enums so they could be refactored, but IntelliJ is able to refactor (in this case rename) the string union types

A recent example is that I removed all import cycles from our app last week (there where over 200) and I was able to do this purely with the IntelliJ "move symbols" refactor in a codebase of xxx,xxx lines of typescript. I can't figure out how to move a symbol to another file with LSP. I spent the first year of development at my current job when working on the front end and I'm simply more productive in IntelliJ compared to vim - I'm in vim for everything else tho (as long as it's not kotlin/java as I can't get LSP working for JVM projects).

https://www.jetbrains.com/help/idea/react.html#react_refacto...

I can't even get Neovim to run stably without throwing random errors every now and then, especially after I update plugins.

Regarding stability - pinning plug-in versions could be helpful. That’s what I’ve done and I’ve never had an issue with stability.

For the last week, I have been playing with Neovim in spare time using a setup based on https://github.com/LunarVim/nvim-basic-ide It does pinning plug-in too.

It's working well for small projects so far.

https://github.com/github/copilot.vim

Copilot + nvim + Termux makes it reasonable to code on a phone.

For file browser side-panes there are tons of options, but no one ever got fired for using the venerable old NERDTree.

The rest is mostly just tmux!

  nvim-telescope/telescope.nvim // integrates well with code actions and searching (very extensible in general, similar to ctrl-p)
  hrsh7th/nvim-cmp
  hrsh7th/cmp-nvim-lsp // for language server completion
  neovim/nvim-lspconfig // a bunch of language server specific stuff

If you want to see what a preconfigured IDE-replacement might look like you can take a look at lunarvim(but beware, it misbehaves on windows quite a bit, you're better of with a linux system here)

It sucks because I want to use vim for TypeScript dev but I just can’t stand it compared to VS Code. For non-typed languages I still use vim, and I love how I can fluently edit anything on servers I shell into, but I kind of wish there was a middle ground of some kind.

In terms of turning things off, if you turn them off, then what’s the point of having the language server? (Not a rhetorical question - I would describe myself as a workaday programmer, not a master by any means.)

Code navigation and completion, for one.

But there are plenty of knobs to turn that provide a spectrum between “show nothing” and “show everything”. I also find the inline diagnostic text noisy, so I configure it to only show on the line where my cursor is. You can also use the “open_float” function to open the diagnostics on your current line in a floating window. That way you can leave them off my and simply view them on-demand.

https://marketplace.visualstudio.com/items?itemName=vscodevi...

Full disclosure: it’s been years since I used it, but I was super impressed

https://github.com/relaxdiego/dotfiles/blob/main/run_once_07...

coworker #2 was struggling with his vscode autodeleting some imports

strange times when you are the vim developer in the house and the one with the most solid IDE...

https://github.com/NvChad/NvChad

coc.nvim (https://github.com/neoclide/coc.nvim) is a great starting point though!

- vim, neovim, Emacs configured with LSP - https://git-scm.com/ - http://aspell.net/ - https://github.com/tmux/tmux - https://github.com/dbcli

Emacs also exists which runs in the terminal mostly (I only miss image rendering personally).

Collaborative editing is something I don't do much of but would guess there's a neovim plugin which could be used for backend sync.

Interacting with your issue tracker depends on the issue tracker software you use (flat file would work for example, Jira has unofficial clients, etc).

- https://www.emacswiki.org/emacs/JiraMode - https://marketplace.atlassian.com/apps/6398/jira-command-lin...

DataGrip wipes the floor with pgcli

How do you find duplicate code with that setup?

"Can you run multiple static analyzers simultaneously"... That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with something like tmux!

Most of the editor questions were also answered by my original post (and the answer was yes).

For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame)

> That's sort of the point of *nix systems: multiple processes running simultaneously. Using the shell is of course going to allow that, especially with something like tmux!

I meant getting a consolidated list of from them, and also having the ability to run corrective actions.

> Most of the editor questions were also answered by my original post (and the answer was yes).

Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.

The shit I've seen IntelliJ users do in git repos is insane. Somehow they create merge commits between their local branch and the origin version of their branch. They've lost changes, rewritten history, all sorts of shit, with 0 understanding of what or why. I'm guessing the warnings come as a pop-up and people instinctively just click ok without reading.

> Sure, but how much crap do you have to memorize? It's not a unified experience. It's a duct-taped Frankenstein where every subsystem works differently.

From your replies it's pretty obvious you have made up your mind. But what you are describing is my exact experience with JetBrains. The good thing about JetBrains tools is that their language analysis stuff is truly state of the art and significantly better than the equivalent LSP stuff out there. Apart from that everything is a Frankenstein setup that works differently.

In vim, all those plugins are just splits. So I can navigate between them with just ctrl+w->h/j/k/l (most people rebind to ctrl + h/j/kl). Each split supports the vim hotkeys by default, because that is the design of vim.

In intellj it's an incoherent mess. Every pane has some weird fucking hotkey that makes 0 sense. You cannot just go "select the pane on the left). The hotkey is ctrl+shift+alt+7 or something insane, to the point where it's not worth it and you just need to click everything.

IDK, my experience with JetBrains is it's leaky abstractions all the way down, outside the core edit/refactor features. Using JetBrains Git without knowing git... I mean, I've seen people do it, but they seem pretty frustrated and confused when things go wrong.

I'd rather just learn the underlying tool once, rather than the underlying tool and also the leaky wrapper around it too.

tig is great at that. "tig blame" and "," is the way to go for researching the history of some code.

> For some things. But for reviewing activity in git, and tracking changes across time, doing it in the terminal is unproductive and sucks. (e.g.: 10 levels deep of git blame)

Magit[1] in Emacs is quite okay. It doesn’t feel duct-taped. I haven’t used fugitive[2] in Vim but that’s a thing that exists too.

[1] https://magit.vc/

[2] https://github.com/tpope/vim-fugitive

But I think you mean how do I refactor duplicate code?

lsp-mode (https://emacs-lsp.github.io/lsp-mode/page/main-features/) for smart code navigation or projectile-replace (mentioned in https://with-emacs.com/posts/tutorials/search-and-replacemen...) for dumb replacements.

LITERALLY BUILTIN: - Edit code - Do all that remotely or with containers involved - Spell checking

ALE: - Autocomplete - Navigate code, find references, go to definitions - Run multiple static analyzers simultaneously

DISPATCH: - Run your code - Debug your code - Test your code (including running a specific test) - Profile your code

FUGITIVE: - Use version control and annotate code using version control

Mastering the commandline is of course still important, just please not for editing code.

And if you install a proper plugin that uses language servers, you're at the same level of VSCode, which I'm pretty sure is the most used editor by a wide margin.

Your rant sounds more like you're more annoyed by "wannabe-vim-hackers" than any actual limitations of the tools.

The main problem with VIM is that nobody reads the documentation, and jumps directly trying to configure vim to imitate what they experienced with other softwares.

Most VIM users never understand VIM philosophy and inner mechanism supporting it. They just try to bend VIM into another graphical code editor.

It's like the meme about "exiting vim". It is pointless. Once you understand VIM you never need to exit it. Just Ctrl-z or use neovim terminal if needed.

The best challenge i was given by VIM guru, when i was asking help installing dozen of plugin, was to read the vim doc (:help) and just use for 6 months a VIM pure vanilla, without any plugin and minimal vimrc. After more than 20 years using VIM daily, i just understood i never learn how to use VIM and were just an adept of CARGO-CULT, victim of mass spread anti-pattern.

What are some examples of plugins people commonly use that you think are useless?

I recommend learning about Unix and the associated philosophies - you sound like there’s a lot more growth in your future!

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

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!

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 work mbp M1 was having a delay writing text in external monitor

While all the rest, including vidéo, was display without delay.

I had to tweak some driver settings ( of the base , not my graphic card )

[1] https://apps.apple.com/us/app/is-it-snappy/id1219667593?plat...

Some of the kernel changes that are happening may well make it possible to have simple high-speed framebuffers that can be used for text consoles in the future, so there's still hope.

In my blissful ignorance I could produce just as much effective code on a VNC machine competing with a 1080p Netflix stream on a rural DSL line as I could on a local machine in TTY mode.

The brain is really amazing at what it can adapt to, when I'm typing in a laggy situation it's like "see" the output of what I've typed before it's on the screen and end up being comfortable doing stuff like fixing a typo before it's even been reflected on the screen

However, I've never been tolerant of lag - having a time gap between doing something and having a response just adds to mental workload, it's friction between me and the machine (especially pronounced with IDE's that try to 'help' by taking a second or two to come up with a suggestion, by which time it'll have been left in the dust).

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.

Some glitches for sure and I couldn't actually draw in Excalidraw, but I obviously wasn't expecting to.

Checking my email or chatting though, why bother? The company pays for outlook and slack, I’d just be making my life pointlessly difficult.

Running a bunch of Electron apps to handle basic things slows you down and takes an unnecessary amount of system resources.

Most users can’t automate GUIs to create workflows, assuming the apps and the platform being used even support that.

Scripting CLI tools has existed since the dawn of Unix.

Yes, and that happens regardless. I can turn off notifications and choose when to look at email or Slack or whatever. I can have those apps on my iPad screen and ignore it or put it in focus mode. If you're talking about switching applications that's just a keystroke whether I'm in screen/tmux or in MacOS.

> Running a bunch of Electron apps to handle basic things slows you down and takes an unnecessary amount of system resources.

All of the native apps I use work faster than I do, I don't think they slow me down. System resources have come a long way since the early days of Unix you refer to. None of my devices struggle with low resources. I mainly work on remote servers so that's where I compile and test code and so on, and those machines don't have GUIs or apps hogging up resources.

>Most users can’t automate GUIs to create workflows, assuming the apps and the platform being used even support that.

Sure, and even fewer users can do anything at the command line.

> Scripting CLI tools has existed since the dawn of Unix.

I remember. That happened about four years into my career as a programmer. I didn't start to see Unix in the wild for a few more years. Scripting CLI tools pre-date Unix but they sure got nicer when Unix took over.

I'm happy to use the command line for almost everything I do in terms of programming. But some of what I do to keep my customers happy involves communicating with them, reading stuff they send, etc. I can't force my customers to stop sending PDFs or HTML emails or links to Zoom calls, nor would I want to. And I'm not going to live with 1970s technology in imitation of Richard Stallman, because however great the terminal and Unix CLI can work for so many things, they aren't the best tool for everything.

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.

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.

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.

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

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

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.

Rather. 99% of what I use tmux for is both: not what I would consider "power user" skills; what I think terminal emulators like kitty or iTerm2 will mimick anyway; and reflects how e.g. VSCode arranges its open files.

I find it convenient to have a session of tabs for a particular task/project, and to switch between the tabs depending on what I want to do.

That said, I rarely make use of split panes (nor a tiled window manager). YMMV, but I almost always want whatever I'm looking at to be fullscreen.

Zellij at least shows the keyboard shortcuts.

In computing, students want to do their coursework on their iPad in a notebook environment, relying mostly on step-by-step instructions given as PDF file or from an online tutorial, based on copy & paste, without understanding what they paste there instead of compiling libraries or write a makefiles from scratch.

Starting next summer, I will include a 2-3 hour UNIX command line (and also a 2-3 hour LaTeX) intro into all courses I teach where that can be justified. (The UNIX Power Tools [1] book is a useful resource for teaching, I found in the past.)

[1] https://www.amazon.de/Unix-Power-Tools-Classique-Us/dp/05960...

That's great to hear. If I were in a position to introduce students to the terminal, I'd also try to expose them to the existence some modern CLI tools so they don't feel like they're trapped in the 1970's.

Something like Starship, tmux/byobu, enabling colors, exa/lsd for ls replacements, dust for a modern take on du, easy terminal editors like micro to ease students into editing text in the terminal, along with mentioning how Vim/Emacs can be used in places of editors/IDEs. They'll get to see that the terminal is both modern and relevant, with ample use of color, font weighting, emojis, images, text GUIs, window management via tmux, etc.

I obviously wouldn't make that the focus, but as a quick aside about the tools they can use with some screenshots or screensharing my own terminal setup might keep some students interested.

Apparently some professors are leaning more and more on desktop & cloud IDEs, and other development platforms that just let students code and not worry about the rest. The argument is that abstracting away system administration allows teachers to spend more time on the content they need to teach versus spending time setting up and debugging systems.

Having said that I concur it's true what you say, there isn't somewhere to go at many universities even if students are interested - the command line hasn't got much of a place in modern curricula - but recognizing that we must fight it (employers talking to deans helps a lot! Universities are more customer-oriented than ever in history).

Depends on what you mean by recent. I wouldn't expect exposure to have been greater 10-15 years ago. If anything, I would expect CLI exposure to be greater now compared to then, at least because of the rise of git.

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.)

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.

There are occasional times I need to pull it out, however. But with Yabai + Vimium + terminal the majority of my day-to-day needs are met happily mouseless.

> 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.

neovim - text editor

aerc - email

nzbget - usenet

irssi - chat

mpv - audio

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

- 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

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.

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.

[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.

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

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

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.

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.

Some CLI browsers have JS support but what's missing is up-to-date support. The existing browsers have way too much technical debt so adding something like TUI support would be quite difficult. You'd really want to start from a newly-developed engine such as the new Ladybird browser that's part of the SerenityOS project.

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.

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!

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?

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.

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).

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

https://github.com/rkd77/elinks

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 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.

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..

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.

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've been in the situation where I needed to config VSCode plugins to use one of the WSL environments and I'm never sure which `git` is being run (if it's the one that runs on Windows, the one in the WSL1, or the one under WSL2. The machine also disagrees with itself about what constitutes an end-of-line marker.

I'd honestly be much happier if the company either gave me a Mac (new office teething problems - third employee in the country - made my original order lost in transit, never to be found again) or allowed me to rip out Windows and install a saner OS on the hardware, which, apart from the UK keyboard, is not terrible.

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.

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 ?)

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.

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.

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

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.

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

I’ve settled on WezTerm [1] for now but Alacrity and Kitty are also impressive.

[1]: https://wezfurlong.org/wezterm/

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

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.

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

1: https://aerc-mail.org

Sure you can get away with it but vim plugin is no where close to what you can do in Idea. Not even in the same orbit.

This sounds like something written from the 1990s.

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

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.

weeslack works fine

https://www.ubuntubuzz.com/2012/04/play-movies-in-ascii-art-...

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

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.

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.

You largely can restrict yourself to phone calls and postal mail. Aside from ordering from Amazon, my dad largely does. (Albeit in part because my brother and I will do various things for him he can't figure out how to do with just a phone call or letter.) But it's increasingly difficult for a lot of things and is, at a minimum, less convenient.

And, as you say, in business you generally don't really have the option to basically refuse to use a computer for many purposes.

This seems like rose colored glasses, maybe there was a very small period of time where there was a wide variety of things you could do in a terminal, but for business purposes it was mostly native GUI’s which suffer from the same problems as the web if not worse (maybe only better because they were harder to make so there were a lot less of them)

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

As bad as the web is, I certainly don't miss the days when I had to go to a physical office, wait minutes, sometimes hours, in a line and talk to somebody that may or may not help me, depending on how their day was going. Thanks but no thanks.

The modern web seems pretty great to me. Why do you feel that way?

* Accessibility - I can't change presentation to make things easier for me to consume

* Inspectability - I can't search, index, etc. Information is hidden behind js driven interfaces that only present bits at a time.

* Uniformity - I don't want to deal with a deluge of clever interfaces. I want the data only, and I want control over how I will present the data to myself.

* Buggy - All these custom JS driven interfaces means a never ending deluge of weird interaction bugs, most of which we just ignore. Pages are needlessly slow or error prone.

Google reader was nice, a day Google kill it, GitHub seems to be nice for some cohort of users, a day a political move between some countries makes your account locked, a day your ebook reader+service cease to exists with all books you never own but being convinced of the contrary, a day your smart vacuum cleaner stop to work because an AWS service have issues etc.

That's how pretty it is. Pretty to capture you, ugly once you discover you are trapped and than it's too late.

Oh, sure in mere tech terms you might run webapps locally, they are still NOT AT ALL pretty behind sugar-eye graphics, since integrate things, bend things is a nightmare that demand a gazillion SLoC for anything, while on classic CLI or better systems like Emacs you can do it in a snap. Not only: anything you'll learn on classic systems is valuable normally for a lifetime and more, anything you learn for the modern web might be valid for few years but generally last far less and no, you can't advance, you can only remain afloat keep learning the new crap on and on.

My point is:

- modern TUIs, called by most CLIs, compared to modern GUIs (widget based GUIs and WebUIs) are more powerful because AT LEAST they allow limited easy user extensibility and composability (scripts and unix IPCs);

- classic GUIs, in the sense of document UIs, like Emacs, like old Xerox Tioga etc, on contrary can be called 2D CLIs in modern lingo and they are FAR superior both of TUIs and modern GUIs because they are "graphical" and they are even more extensible and composable than TUIs.

That's is. Modern developers regularly push toward classic GUIs without knowing them, think for instance how popular Notebook UIs have became. WebUI themselves as a "more like documents" widgets-based GUIs. Still are are far behind classic document UIs.

A quote I once heard about the modern web browser: "I want this program to do everything my computer already does."

Imagine a simple hypertext markup language which tells a program how to render the text, link to different text or sites and perhaps paint some images on a screen. Seems pretty strait forward. Now make that program into a worse computer. This is what makes many people nauseous when they attempt to build "modern web" things.

I heard a great comparison of game dev to web dev: "You write programs to reach goals or a finish line. game dev feels like you're building and fine tuning a race car. Web dev feels like you're running a marathon in the rain and everyone is throwing garbage at you while booing."

Web sites that require JS to function (and there are many) is a bigger deal.

Same with pictures.

It's much more realistic to run a graphical environment and use a regular browser. Just disable JS by default and put a reasonable ad blocker. Then whitelist sites where you really need JS to work, like your Jenkins host :)

A reasonable PDF viewer is also not such a resource hog, same with picture viewers when you need to display pictures. Say, Firefox does a reasonable job of being both if you don't want to install dedicated software.

You can make a graphical environment which is snappy, low-distraction, and very usable. (That was definitely already possible 20 years ago, when my Linux desktop was my main working machine, and ran quite adequately on a tiny fraction of today's laptop resources.)

This seems backwards. Limiting yourself to CLI tools do retard your abilities, modern GUI apps do not.

CLI respect of Emacs yes, is limited and limiting, but modern GUIs are FAR more limited and limiting. Can you integrate them? No. Let's say you want in a single view a set of mails, financial transactions, notes etc. You can arrange something in a CLI, you can do it in org-mode, you can't do it in the most advanced ERP monster.

Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare.

If you limit the capabilities of a GUI interface to only what is possible without code changes, then you must do the same for CLI applications.

Emacs is all code. Most CLI-only applications cannot be modified other than the flags you pass in; you are instead forced to pipe from one application to another.

If you limit the capabilities of GUI applications to the realm of existing software (i.e. your monster ERP reference) then we must also limit the capabilities of CLI tools to what exists, and I know (for having looked far and wide) that I have needs which are not available via terminal-only programs; the only existing set of available software that I need with a comprehensive set of features is in a GUI-only application.

They quickly drop such idea introducing GUIs, who fail to offer composability and scripting, and they derailed hitting their own design limits. Modern GUIs are the monster emerged form such ashes who happen to be worst than the problem it try to solve. The issue in the example comparison in my previous post is that at least in CLIs you can combine/compose a bit, with modern GUIs you can't. Write a script is easy, at least FAR easier than change an ERP.

I'd agree that some GUIs are bad, but the same could be said about some TUIs.

On a terminal, I can run a terminal based editor who typically can run code from inside the text buffer. In Emacs I can do much more in both terminal and X11. That's is.

My org-mode notes links anything, meaning mails (searches, specific messages, threads), financial transactions (ledger), elisp code, for instance to act on notes themselves like an `* Online retails orders` heading with a "click here to add a new one" or to change the Emacs/EXWM graphic, for instance to present something, org-ql queries on my notes etc. In pure CLI (not TUI) I can at least cat and process programs output, in modern GUIs I can't.

A simple showcase: https://youtu.be/B6jfrrwR10k

GUI apps can and sometimes do provide interfaces for programmatic use.

And some terminal applications fail to follow conventional Unix patterns.

>Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare.

I don't see this as a bad thing. I want someone responsible for the product to figure out the best way to use it via a focused set of controls and inputs. Some people fail at this, others are amazing.

In CLIs you need a way to query in text all such elements, you are limited by the limited and limiting Amazon WebUI who do not offer anything cat-able, even not anymore a manual *sv export. Not much different is the situation on your bank side where if you are lucky you just get manual ofx/qif export.