As someone who uses both vim/tmux and emacs for certain things (and spent years configuring and working only in emacs), my emacs setup is WAY more ad hoc, informally specified, and bug ridden than my vim+tmux setup ;)
The key point you're missing from the parent comment is "half of".
Maybe you have no idea how much Elisp code is out there in the wild. There is a LOT of things written in Emacs Lisp. Elisp is probably the most widely used Lisp, with the global total codebase amount exceeding both Clojure and Common Lisp combined.
There are things built into Emacs that some specialized apps don't even have. Did you know that Emacs has built-in lunar and solar calendars, for example?
Just by comparing the sheer amount of code, of course vim+tmux may feel less complicated - they give you fewer opportunities to encounter complexity because they offer significantly less functionality out of the box.
I'm aware! I used emacs exclusively in professional development roles for years. I still use it for a handful of things that nothing else can touch emacs' workflows for.
That said, there is something nice about composing simple programs and keeping things small. With vim + tmux, I have terminal multiplexing and text editing done and haven't touched that configuration in at least 5 years for vim, over 12 for tmux. I know they offer 'less functionality' out of the box, but after years of tweaking and tons of installed packages I was never able to get that same functionality in Emacs, try as I might.
The main pain points were:
- Not having tmux's <c-b z> functionality. You can kinda-sorta-almost jerryrig it with some custom bindings and winner-undo, but you'll still have weird edge cases to think about because you're technically doing a weird undo-tree thing, and all the context (projects, windows, buffers, etc) that emacs maintains will have something to say about that.
- ACTUAL vim emulation. Evil mode is really not good enough, and I never had a package that was so hard to integrate without bugs, and when it breaks you have to usually peel back a massive layer cake of competing configurations to try to make it work. Even then, evil-magit has tons of issues, the dot operator doesn't work correctly, and none of the ctrl-i/ctrl-o plugins work across enough contexts to make it make sense like it does in vim. That's a killer feature for me
- Embedded terminals that feel anything like tmux in wezterm. In the emacs terminals, there was always so much shit going on navigating in them (and again the layer of evil there) that it felt like walking on egshells using them, they tended to have performance issues and usually couldn't run TUI programs properly. I ended up having a separate drop-down terminal I used in tandem with emacs
- Process management. It was always a huge headache for me keeping track of the processes Emacs was spinning up / down through its various plugins and debugging them.
I'd say most tmux+vim setups have something more like 0.00001% of emacs implemented, but sometimes that's a good thing. And again, I love and use both setups for various things.
What the heck are you even talking about? (delete-other-windows) command existed since at least Emacs 18 (released in 1987).
Okay, yeah, I get it, you're complaining that Emacs sorta lacks a dedicated "zoom toggle" that cleanly saves your exact window layout, maximizes one window, then perfectly restores the layout when toggled again. I personally never had any problem with my (toggle-maximize-buffer) command that builds on top of (delete-other-windows)
But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state. There are buffer associations, point positions in each buffer, window-local vars, display parameters - margins, fringes, etc., there could be integrations with modes that manage window layouts, there are multiple abstraction layers - framers, pos-frames, buffer display rules.
tmux can get away with a simple layout save/restore because panes are just rectangular terminal regions.
> Evil mode is really not good enough
Ha, I'm a die-hard vimmer, and I laugh at this sentiment. You, my good Sir/Madam/etc., respectfully, have no idea what you're talking about. Evil-mode is the only ACTUAL vim emulation outside of vim/neovim. There's no such thing as a "vim emulation". And I've tried them all - different ones - IdeaVim for IntelliJ, Sublime Vim plugins, VSCode extensions, etc. All of them are pretty much filled with laughable deficiencies; they are not even shadows of the actual Neovim
experience. With one notable exception, and that is the vim-implementation in
Emacs. In Emacs, Evil-mode doesn't even feel like an extension, an afterthought;
it feels like it's a baked-in, major feature of the editor. More than that, it
can do certain things even better than you can do it in Neovim.
Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input. Like I said before, it's of course absolutely obvious that things of lesser capacity will have smaller surface area and thus would feel more stable.
What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names. I hope you'd realize how vain this kind of argumentation is - comparing things of completely different caliber.
This is a very haughty response, I hope you realize that. Yes, (delete-other-windows) does exist. It's so far from the buffer zoom toggle I'm talking about as to be completely unrelated.
> Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input.
I have given multiple specific examples of every claim that I made. HN's formatting did make my comment difficult to read, but the content is there.
> But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state.
Yes, yes, this is exactly what I'm saying. It's cumbersome and much more difficult to maintain. There are reasons to like both things (and I have repeatedly made efforts to re-iterate that I do like both options and use both for different purposes).
Your screed about how great evil-mode is does not address any of the specific issues that I have and was never able to resolve wrt using evil-mode in emacs.
> What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names.
Incidentally I wouldn't, especially if your bicycle worked for your lifestyle and the constant attention and expense of motor vehicles factored into your decision making process. That's neither here nor there, though, because I happen to own both a bicycle and a car, and I never made the argument you seem to be fixated on. Like my car and bicycle, I use both a tmux / terminal app based workflow and emacs in different contexts and have swapped back and forth between the two at different points depending on my mood and what I'm doing. Sometimes I even (gasp!) discuss my experiences with the two tools in a comments section.
Although I like the idea of having a full-blown graphics engine built into Emacs, I personally don't suffer (at least not so badly) from not having a real web browser inside of Emacs. I can navigate my browsing history¹; I can even (to a certain degree) control my actual browser from Emacs - going through the list of tabs, jumping to a selected tab, extracting content from a tab, inserting the current URL at point, etc. Some of it can be done with AppleScript (on Mac), some of it can be done using Linux tools like xdotool. I browse HN and Reddit in Org-mode; I've recently built a package to search through HN². I don't really need to jump back and forth between my editor and my browser (or many other apps) all the time.
vim+tmux setups usually lean on system primitives = pipes, files, signals, scrollback so the tooling tends to stay transparent across environments. that gives them an edge in portability and debugging, especially over ssh or in constrained shells. it's just lets your workflows shaped around different guarantees so natively, it naturally makes building your own vim config an obvious choice
- Sudo seamlessly: /sudo::/etc/hosts or /ssh:host|sudo::/etc/config
- And even combine them: /ssh:server|docker:container|sudo::/etc/nginx/nginx.conf
What you get? Transparent integration - Dired, Magit, etc, they just work. There's no context switching - you stay in your configured Emacs environment. Your keybindings, packages, customizations remain the same. It's multiprotocol: Supports SSH, FTP, SMB, ADB (Android), and more.
it also doesn't quite work with macOS remotes usually.
again, not purely TRAMP's fault, but a default config and habits issue with ~/.zshrc vs ~/.zprofile and maybe /etc/sshd/config settings, i think. i hasn't fully figured it out yet.
using this kind of "full-screen terminal screen sharing" approach has a more predictable experience, because of the amount of data transferred is usually 1 screen worth of characters (and colors) max, on most keystrokes.
that's both a pro and a con.
it imposes a fixed, network connection dependent input lag and the output is also often redrawn by retransmitting the same data over and over again...
I even wrote a little terminal emulator turn my 2-key tmux prefix into the single-key ctrl modified for every command, including the ones that are normally impossible on other terminal emulators
